add `--revision` support to Git shallow clones

When you add a `steps.Git(shallow=True)` it breaks builds that try and checkout a specific commit since that commit is not pulled down unless it's the latest commit.

A solution to this would be to use the `--revision` flag https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---revisionrev which would allow a shallow clone of a single commit.

For example:

This doesn't work
```bash
git clone https://github.com/buildbot/buildbot --depth=1 .clone1
(cd .clone1; git checkout 4f53e92b0f0d8ca237d2225c05af6b745e691a05)
```

However this would work
```bash
git clone https://github.com/buildbot/buildbot --depth=1 --revision 4f53e92b0f0d8ca237d2225c05af6b745e691a05 .clone2
(cd .clone2; git checkout 4f53e92b0f0d8ca237d2225c05af6b745e691a05)
```

I don't really understand what the purpose of a shallow clone is if you're stuck with only the latest commit.

If there is a concern about this being a breaking change, a key like `shallowFromRevision` can be added which defaults to `False`.
If it's set to `True`, it uses the revision of the commit it's trying to checkout.
(I can't think of a use for it, but perhaps passing a string to it would use that instead of the change revision)

This new key would conflict with `branch` but I don't think it needs to be more complicated than an AssertionError

Start at the steps.Git(shallow=True) entry point and inspect how the git clone and checkout commands are assembled. Compare the two command examples, then verify that a shallow checkout can target the requested commit with --revision and that the branch conflict behavior is handled as described.

Written by the indexing model from the issue text.