When we see PARENT1, it means there is a local commit and thus we are
ahead. Likewise, seeing PARENT2 means that the upstream branch has a
commit and we are one more behind.

The logic is currently reversed. Correct it.

This fixes #2501.

git_merge_base() returns GIT_ENOTFOUND when it cannot find a merge
base. graph_desdendant_of() returns a boolean value (barring any
errors), so it needs to catch the NOTFOUND return value and convert it
into false, as not merge base means it cannot be a descendant.

git_graph_descendant_of was returning the result of an assignment

I accidentally wrote a separate priority queue implementation when
I was working on file rename detection as part of the file hash
signature calculation code.  To simplify licensing terms, I just
adapted that to a general purpose priority queue and replace the
old priority queue implementation that was borrowed from elsewhere.

This also removes parts of the COPYING document that no longer
apply to libgit2.

Explain it in local-upstream branch terms so it's easier to grasp than
with the `one` and `two` naming from the merge-base code.

If commit timestamps are off, we're more likely to hit a traversal
where the first path ends up traversing past the root commit of the tree.
If that happens, it's possible that the loop will complete before the second
path marks some of those final parents. This fix keeps track of the root
nodes that are encountered in the traversal, and verify that they are
properly marked.

In the best case, with accurate timestamps, the traversal will continue
to terminate when all the commits are STALE (parents of a merge-base), as
it did before. In the worst case, where one path makes a complete traversal
past a root commit, we will continue the loop until the root commit itself
is marked.

Integrate mark_parents() with the ahead_behind() code.