Make submodules externally refcounted

Update behavior for untracked contained repositories

clone: don't overwrite original error message

This cleans up some places I missed that could hold onto submodule
references and cleans up the way in which the repository cache is
both reloaded and released so that existing submodule references
aren't destroyed inappropriately.

When a directory containing a .git directory (or even just a plain
gitlink) was found, libgit2 was going out of its way to treat it
specially.  This seemed like it was necessary because the diff
code was not originally emulating Git's behavior for untracked
directories correctly (i.e. scanning for ignored vs untracked items
inside).  Now that libgit2 diff mimics Git's untracked directory
behavior, the special handling for contained Git repos is actually
incorrect and this commit rips it out.

Callback function to hide commit and its parents in revision walker

`git_submodule` objects were already refcounted internally in case
the submodule name was different from the path at which it was
stored.  This makes that refcounting externally used as well, so
`git_submodule_lookup` and `git_submodule_add_setup` return an
object that requires a `git_submodule_free` when done.

env test needs to deref git_buf's ptr

Refactor the `git_merge` API

settings: use git_buf for returning strings

The default cache size is 256 megabytes, not megabits as claimed in the
docs.

This survived the last round of culling, as the signature is only in the
comments.

Fix wrong assertion

Fixes issue #2196

revwalk: don't try to find merge bases when there can be none

As a way to speed up the cases where we need to hide some commits, we
find out what the merge bases are so we know to stop marking commits as
uninteresting and avoid walking down a potentially very large amount of
commits which we will never see. There are however two oversights in
current code.

The merge-base finding algorithm fails to recognize that if it is only
given one commit, there can be no merge base. It instead walks down the
whole ancestor chain needlessly. Make it return an empty list
immediately in this situation.

The revwalk does not know whether the user has asked to hide any commits
at all. In situation where the user pushes multiple commits but doesn't
hide any, the above fix wouldn't do the trick. Keep track of whether the
user wants to hide any commits and only run the merge-base finding
algorithm when it's needed.

reflog: follow core.logallrefupdates

On bare by default, or when core.logallrefupdates is false, we must not
write the reflog.