[PATCH 0 of 8 V2] revset predicates for graft/rebase/convert

[Matt Harbison]

This collapses most of the predicates into origin() as Matt suggested in the previous thread, and I think addresses all of the other points raised.  Converted() can't be folded into origin() and it didn't receive any comments previously, so I only cleaned up the commit message and name here, and added a test.  I have no problem with queuing it while hashing out the rest.

I also added a predicate ('destination') to essentially go in the opposite direction of origin.  There was a bug filed recently to add the source hash to the comment of a graft like transplant does (which was done), so going backward also seems useful.  I'm not hung up on the name if anyone has a better suggestion- it came from a thesaurus, and 'destiny' was the only other thing that was even somewhat reasonable.

I initially thought following the cset copies transitively was way overkill, but I was surprised by the different behavior between graft and transplant without it, so I implemented it anyway and submitted both versions in case anyone wants to compare the differences on a real repository.  The more I think about it, the more I think the transitive ones are the desired versions, so I can qfold the naive and transitive patches into one if that is agreeable.

Finally, there are filters for each (similar to head vs heads).

The only question I have is the transitive versions attempt an optimization by starting at the beginning, going forward and trying to build off of the previously discovered lineage when available, instead of repeating the source lookups near the beginning of the repo.  But this assumes that local rev ids are assigned in such a way that a source cset will always have a smaller value than the destination created by graft/transplant.  Seems true in the normal case, but I have no idea if there is functionality that breaks this (I'm specifically thinking about convert --branchsort).