git_rebase_finish relies on head_detached being set, but
rebase_init_merge was only setting it when branch->ref_name was unset.
But branch->ref_name would be set to "HEAD" in the case of detached
HEAD being either implicitly (NULL) or explicitly passed to
git_rebase_init.

`git-rebase--merge` does not ask for time sorting, but uses the default. We now
produce the same default time-ordered output as git, so make us of that since
it's not always the same output as our time sorting.

It looks like we're getting the operation and not doing anything
with it, when in fact we are asserting that it's not null.  Simply
assert that we are within the operation boundary instead of using
the `git_array_get` macro to do this for us.

When rebasing with IDs, we do not return to the `branch`,
we remain in a detached HEAD state.

When `init`ing a rebase from a detached HEAD, be sure to remember
that we were in a detached HEAD state so that we can correctly
`abort` the object that we just created.

Convert `rebase_alloc` to use our usual error propagation
patterns, that is accept an out-parameter and return an error
code that is to be checked by the caller. This allows us to use
the GITERR_CHECK_ALLOC macro, which helps static analysis.

When performing an in-memory rebase, keep a single index for the
duration, so that callers have the expected index lifecycle and
do not hold on to an index that is free'd out from under them.

Allow callers of rebase to specify custom merge options.  This may
allow custom conflict resolution, or failing fast when conflicts
are detected.

Introduce the ability to rebase in-memory or in a bare repository.

When `rebase_options.inmemory` is specified, the resultant `git_rebase`
session will not be persisted to disk.  Callers may still analyze
the rebase operations, resolve any conflicts against the in-memory
index and create the commits.  Neither `HEAD` nor the working
directory will be updated during this process.