Using an `enum` causes trouble when used with C++ as bitwise operations are not possible w/o casting (e.g., `opts.flags &= ~GIT_BLOB_FILTER_CHECK_FOR_BINARY;` is invalid as there is no `&=` operator for `enum`).

Signed-off-by: Sven Strickroth <email@cs-ware.de>

In libgit2 nomenclature, when we need to verb a direct object, we name
a function `git_directobject_verb`.  Thus, if we need to init an options
structure named `git_foo_options`, then the name of the function that
does that should be `git_foo_options_init`.

The previous names of `git_foo_init_options` is close - it _sounds_ as
if it's initializing the options of a `foo`, but in fact
`git_foo_options` is its own noun that should be respected.

Deprecate the old names; they'll now call directly to the new ones.

This moves the current merge analysis code into a more generic version
that can work against any reference.

Also change the tests to check returned analysis values exactly.

Allow for a custom conflict marker size, allowing callers to override
the default size of the "<<<<<<<" and ">>>>>>>" markers in the
conflicted output file.

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

Allow merge users to configure a custom default merge driver via
`git_merge_options`.  Similarly, honor the `merge.default` configuration
option.

`git_merge_commits` and `git_merge` now *do* handle recursive base
building for criss-cross merges.  Remove the documentation that says
that they do not.

This reverts commit 5e44d9bcb6d5b20922f49b1913723186f8ced8b5.

Add a simple recursive test - where multiple ancestors exist and
creating a virtual merge base from them would prevent a conflict.