Without much detailed knowledge of Jenkins, I would guess that for
(1) Polling and starting a build based on a change to a git-slave git repository or its children
you will have to write a plugin at one end or the other. If you don't want to write a Jenkins plugin, you will need to write a Git post-receive hook or something like that, which could trigger the Jenkins build for the repo (or its parent if it is a slave). Setting up the post-receive hook is probably nicer since it eliminates polling overhead, and this question provides a link to a blog post that talks about doing this.
For (2) Printing out the commits in all repositories since the previous build
the most likely approach would seem to be having the Jenkins build putting a tag on the repo and slaves/children using gits tag
when it completes a build, and then using something like gits log $last_build_tag..HEAD
to show all commits since that build. I would not recommend recycling the tags but rather using multiple timestamped ones (e.g. jenkins-build-2013-06-19-10-24) and pulling the $last_build_tag from the output of git tag | sort -nr | sed '/jenkins-build/q'
(no need to use gits tag
as presumably the set of Jenkins tags will be the same for all repos).
These tags will definitely clutter up the tags space, ideally you would make these on a repo that only pulls from others, so that you don't push those tags out and mess up all the other repos.