Use the new object_type enumeration names within the codebase.

C++ style comment ("//") are not specified by the ISO C90 standard and
thus do not conform to it. While libgit2 aims to conform to C90, we did
not enforce it until now, which is why quite a lot of these
non-conforming comments have snuck into our codebase. Do a tree-wide
conversion of all C++ style comments to the supported C style comments
to allow us enforcing strict C90 compliance in a later commit.

Virtual base building: ensure that the virtual base is created and
revwalked in the same way as git.

When the commits being merged have multiple merge bases, reverse the
order when creating the virtual merge base.  This is for compatibility
with git's merge-recursive algorithm, and ensures that we build
identical trees.

Git does this to try to use older merge bases first.  Per 8918b0c:

> It seems to be the only sane way to do it: when a two-head merge is
> done, and the merge-base and one of the two branches agree, the
> merge assumes that the other branch has something new.
>
> If we start creating virtual commits from newer merge-bases, and go
> back to older merge-bases, and then merge with newer commits again,
> chances are that a patch is lost, _because_ the merge-base and the
> head agree on it. Unlikely, yes, but it happened to me.

Git uses longer conflict markers in the recursive merge base - two more
than the default (thus, 9 character long conflict markers).  This allows
users to tell the difference between the recursive merge conflicts and
conflicts between the ours and theirs branches.

This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f.

Update our tests to expect this as well.

Test that shows that submodules are incorrectly considered in renames,
and `git_merge_trees` will fail to lookup the submodule as a blob.

When `GIT_MERGE_FIND_RENAMES` is set, provide a default for
`rename_threshold` when it is unset.