PR/25 merge/rebase

Fixes the ./test/failing/test.sh failing test case I submitted.

I solve this problem by finding a better *common-ancestor* before merging. This *common-ancestor* search is necessary as otherwise the *git merge* command using the $subrepo_parent obtained from the .gitrepo file as the *common-ancestor* would fail. I believe this is because the merge command internally calls `git-merge-base`, which isn't sophisticated enough to find the best *common-ancestor* in this context (due to one branch having the .gitrepo file and the other not). We must do this search manually by comparing the trees without the presence of the .gitrepo file.

Previously I had solved the problem by ***caching*** when the latest `git subrepo push` command was, and used that point as the *common-ancestor* during the merge (in the `git subrepo pull` command).
 *But that solution wasn't acceptable as the cache only stayed in the local repo- causing problems for other developers as they wouldn't recieve this cache.

Now I have solved the problem by ***searching*** for where the lastest `git subrepo push` command was done, and using that point as the *common-ancestor* during the merge (in the `git subrepo pull` command).
 *This logic was placed into the get-best-common-ancestor-for-merge() function.
 *This search has **M*N** complexity (two loops).
   ***M** (outer loop) is # of commits since last *subrepo clone/pull* in ***subrepo branch***.
     *Essentially iterates over the output of `git rev-list subrepo/$subdir --format="format:%T"`, and stopping once the tree pertaining to the last *subrepo clone/pull* command is reached.
     *A further optimization here would be to call `git rev-list subrepo/$subdir --format="format:%T"` with the --after= argument, where the date is the date of the last *subrepo clone/pull* commit. This might speed up the `git rev-list` command a bit with a large repo.
   ***N** (inner loop) is # of commits since last *subrepo clone/pull* in ***original branch***.
     *Iterates over `git rev-list "$subrepo_parent".."$original_head_branch" -- "$subdir"`, which is the list of commits which modified the subrepo since the last *subrepo clone/pull*.
     *A further optimization within this loop can be made by caching the output of `git mktree < <(git ls-tree "$i:$subdir" | sed -r '/^.*\.gitrepo.*$/d')`. This command is how we look at the tree without the .gitrepo file, so that we can quickly figure out where the best *common-ancestor* is.
 *This commit introduces process substitution (`cmd1 < <(cmd2)`) which introduces portablity concerns: http://wiki.bash-hackers.org/syntax/expansion/proc_subst#bugs_and_portability_considerations

lib/git-subrepo command:pull() changes:
 *When pruning the merge history after the merge in command:pull(), it turns out in some flows I made that HEAD^2 doesn't always exist, so I threw HEAD there as a backup.
 *Wrote get-best-common-ancestor-for-merge which solves my test case without caching subrepo-push commands! It does this by searching for when the last subrepo push was made, then using that as the common-ancestor so that the merge on a subrepo-pull will work. Importantly my technique doesn't use the I/O expensive git-filter-branch in its search.
 *Modified the outer loop so that it would iterate over `git rev-list subrepo/$subdir --format="format:%T"` instead of following the first-parent-lineage from subrepo/$subdir.  Not convinced this is perfect, but is a good start at least.  Might need to use the output of the above rev-list command, then somehow follow each ancestor-branch with matching $outer_loop_term_tree entries.
 *Added an optimization on the inner-loop-element query, by only listing what commits modified the $subdir.

lib/git-subrepo command:push() changes:
 *In the event of a subrepo-push, then an external push to the subrepo from someone else, then a subrepo-pull, the history rewrite would disconnect HEAD^ from all ancestry.  This commit includes a test for that case, by checking (after the merge in the subrepo-pull) if HEAD^ is equal to HEAD^2^, and not rewriting the history in that case. I am certain an improvement can be done here though, as the resulting `git subrepo pull` commit is different than normal and is quite messy.
 *Made rebase in subrepo-push verbose; will be useful if user has to fix things by hand.
 *In subrepo-push the initial rebase onto upstream written by ingy won't always work, but will work if we rebase A..$checkout_branch onto $upstream_head where A is the last clone/merge log entry. I think this `rebase --onto` will work in all cases so should replace the simpler rebase, rather than just running if the simpler rebase failed.

test/failing/test.sh changes:
 *Cleaned up this failing test case I gave ingy by making it simpler; didn't need the bare lib repository.