This could be a half-measure for purescript#33. This does not prevent usage of
master, but it arguably does behave how you'd expect: it always keeps
whatever reference you're using as a package set up to date, and
happens to also allow you to use a SHA in addition to a revision. I'm
going to give this a spin, but if we later wanted to disallow
branches, we could probably cobble together a git command that would
tell us if a tree-ish or whatever they call it is a branch or not.

view actually dumps the exit status, sh does not.

This is for purescript#45. We'll see what the tests say.

Summary:
* I use a newtype for Repo since things were starting to get
complicated differentiating it from tags. Hope that's ok.
* I use the ls-remote trick (you're a lifesaver, @Pauan!) to pull
  refs. If the ref is *proven* to be a branch, bail out with an
  error. If its *proven* to be a tag, we can shortcut the clone
  without running a checkout afterwards. Otherwise, assume its a SHA.
* Restore the "exists" checks since we have decided to treat SHAs and
  tags as immutable. This should avoid unnecessary network calls on
  subsequent runs.

Conflicts:
	app/Main.hs

As per @Paun's suggestion as it returns less extraneous data this way.

In response to recent comments in purescript#45. Now we don't need an expensive
ls-remote call to determine if a clone target is a tag or sha. I'm
still lacking a good way to test this out though.

This is in accordance to the comments in purescript#45

The drop call was not updated when we went from "scheme://identifier"
to "scheme:identifier" and was eating 2 characters from the identifier
when a scheme was specified.