`cabal get` should not reset the default branch to the given tag

Currently, having a package that declares the following `source-repository` stanza in the available repositories (hackage):
```
source-repository this
type: git
location:
tag:
branch:
```
When one runs `cabal get -sthis -d` will perform the following sequence of commands:
```
(cd somedir && git clone --branch )

if [ -n ]; then
(cd somedir/pkg && git reset --hard --)
fi

(cd somedir/pkg && git submodule sync --recursive)
(cd somedir/pkg && git submodule update --init --force --recursive)
```

I would argue that the `git reset` is just wrong. It will reset whichever branch was cloned to the tag, resulting in a state that disagrees with the git server. My proposal is as follows:

1. `branch` and `tag` should be exclusive. To be precise, they could be merged into either of them or some new name. Either way, only one of those has to/should be provided. Probably `ref` or `rev` would be a good name.
2. Invoke `git clone --branch ` as git can handle tags in that argument.
3. As a side improvement, the directory provided in `-d` should be used as the output directory, and not as a parent folder for the clone. This means that using `cabal get -sthis -d` will clone the repo in `./somedir` and not in `./somedir/reponame`. This can be achieved by invoking `git clone --branch `

Note that the same reasoning could apply to `source-repository-package` as those also allow for `branch` and `tag`.