(This is a continuation of http://bugs.darcs.net/patch1375 )

I think repo cloning code should be broken in two cases named after
*what they do*:

(A) get pristine and possibly unapply patches:
        
    For the default case (lazy or not)

(B) get patches to apply to an empty state:

    For old fashioned cloning
    For to-match, can also apply to --tag (currently not the case).

As long as we want to support OF repositories we will have code for
(B), so it's probably worth it to rewrite it into a good abstraction
that would work for all the (B) cases.

I'd suggest:

* reimplement cloning code into two cases (A) and (B) described above
* also end with this nonsense of repeating "identifyRepository" several
  times during cloning

What bothers me is that you could always create repositories with "hard"
patches at the beginning and "easy" patches at the end, or the contrary,
which can make (A) or (B) more interesting than the other one.
So there is no "always better" solution.

Maybe we should provide good enough defaults and a manual switch?

Like:

* when cloning without matcher -> A by default
* when cloning with matcher (including --tag)  or OF repo-> B by default

An then (one further step, needs discussion):

* if user provides --pristine-first / --patches-first flag, default
  behaviour is overrided?

And then (maybe this is too crazy, but we kind of do this already with
packs):

* run A and B in parallel, keep the one that finishes first? :-]