While our debug builds on MSVC platforms already tune the code optimizer
to aid debugging code, all the other platforms still use the default
optimization level. This makes it hard for developers on these platforms
to actually debug code while maintaining his sanity due to optimizations
like inlined code, elided variables etc.

To help this common use case, we can simply follow the MSVC example and
turn off code optimization with "-O0" for debug builds. While it would
be preferable to instead use "-Og" supported by more modern compilers,
we cannot guarantee that this level is available on all supported
platforms.

In our code base, we have some occasions where we use the "_DEBUG"
preprocessor macro to enable additional code which should not be part of
release builds. While we define this flag on MSVC platforms, it is
guarded by the conditional `WIN32 AND NOT CYGWIN` on other platforms
since 19be3f9e (Improve MSVC compiler, linker flags, 2013-02-13). While
this condition can be fulfilled by the MSVC platform, it is never
encountered due to being part of the `ELSE` part of `IF (MSVC)`.

The intention of the conditional was most likely to avoid the
preprocessor macro on Cygwin platforms, but to include it on everthing
else. As such, the correct condition here would be `IF (NOT CYGWIN)`
instead. But digging a bit further, the condition is only ever used in
two places:

1. To skip the test in "core::structinit", which should also work on
   Cygwin.
2. In "src/win32/git2.rc", where it is used to set additional file
   flags. As this file is included in MSVC builds only, it cannot cause
   any harm to set "_DEBUG" on Cygwin here.

As such, we can simply drop the conditional and always set "-D_DEBUG" on
all platforms.

In commit 9f75a9ce (Turning on runtime checks when building debug under
MSVC., 2012-03-30), we introduced a comment "Precompiled headers", which
actually refers to no related commands. Seeing that the comment never
had anything to refer to, we can simply remove it here.

Read prefix tests

Allow creation of a configuration object in an in-memory repository

travis: install openssl explicitly

Given a wholly in-memory repository, ensure that we can create an
anonymous remote and perform actions on it.

When in an in-memory repository - without a configuration file - do not
fail to create a configuration object.

Disambiguate error values: return `GIT_ENOTFOUND` when the item cannot
exist in the repository (perhaps because the repository is inmemory or
otherwise not backed by a filesystem), return `-1` when there is a hard
failure.

Previous to pulling out and extending the fake backend, it was quite
cumbersome to write tests for very specific scenarios regarding
backends. But as we have made it more generic, it has become much easier
to do so. As such, this commit adds multiple tests for scenarios with
multiple backends for the ODB.

The changes also include a test for a very targeted scenario. When one
backend found a matching object via `read_prefix`, but the last backend
returns `GIT_ENOTFOUND` and when object hash verification is turned off,
we fail to reset the error code to `GIT_OK`. This causes us to segfault
later on, when doing a double-free on the returned object.

Right now, the fake backend is quite restrained in the way how it
works: we pass it an OID which it is to return later as well as an error
code we want it to return. While this is sufficient for existing tests,
we can make the fake backend a little bit more generic in order to allow
us testing for additional scenarios.

To do so, we change the backend to not accept an error code and OID
which it is to return for queries, but instead a simple array of OIDs
with their respective blob contents. On each query, the fake backend
simply iterates through this array and returns the first matching
object.

In order to make the fake backend more useful, we want to enable it
holding multiple object references. To do so, we need to decouple it
from the single fake OID it currently holds, which we simply move up
into the calling tests.

The fake backend used by the test suite `odb::backend::nonrefreshing` is
useful to have some low-level tests for the ODB layer. As such, we move
the implementation into its own `backend_helpers` module.

smart_protocol: fix parsing of server ACK responses

odb_read_prefix: reset error in backends loop

When looking for an object by prefix, we query all the backends so that
we can ensure that there is no ambiguity.  We need to reset the `error`
value between backends; otherwise the first backend may find an object
by prefix, but subsequent backends may not.  If we do not reset the
`error` value then it will remain at `GIT_ENOTFOUND` and `read_prefix_1`
will fail, despite having actually found an object.

Update version number to 0.26

CHANGELOG: add various changes introduced since v0.25

Ensure packfiles with different contents have different names

Update to forced checkout and untracked files

Only ignore `EBUSY` from `rmdir` when the `GIT_RMDIR_SKIP_NONEMPTY` bit
is set.

When deleting a directory during checkout, do not simply delete the
directory, since there may be untracked files.  Instead, go into
the iterator and examine each file.

In the original code (the code with the faulty assumption), we look to
see if there's an index entry beneath the directory that we want to
remove.   Eg, it looks to see if we have a workdir entry foo and an
index entry foo/bar.txt. If this is not the case, then the working
directory must have precious files in that directory. This part is okay.
The part that's not okay is if there is an index entry foo/bar.txt. It
just blows away the whole damned directory.

That's not cool.

Instead, by simply pushing the directory itself onto the stack and
iterating each entry, we will deal with the files one by one - whether
they're in the index (and can be force removed) or not (and are
precious).

The original code was a bad optimization, assuming that we didn't need
to git_iterator_advance_into if there was any index entry in the folder.
That's wrong - we could have optimized this iff all folder entries are
in the index.

Instead, we need to simply dig into the directory and analyze its
entries.

If the `GIT_CHECKOUT_FORCE` flag is given to any of the `git_checkout`
invocations, we remove files which were previously staged. But while
doing so, we unfortunately also remove unstaged files in a directory
which contains at least one staged file, resulting in potential data
loss.

This commit adds two tests to verify behavior.

Fix ACK parsing in wait_while_ack() internal function. This patch
handles the case where multi_ack_detailed mode sends 'ready' ACKs. The
existing functionality would bail out too early, thus causing the
processing of the ensuing packfile to fail if/when 'ready' ACKs were
sent.

settings: rename `GIT_OPT_ENABLE_SYNCHRONOUS_OBJECT_CREATION`

Initially, the setting has been solely used to enable the use of
`fsync()` when creating objects. Since then, the use has been extended
to also cover references and index files. As the option is not yet part
of any release, we can still correct this by renaming the option to
something more sensible, indicating not only correlation to objects.

This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also
move the variable from the object to repository source code.

Buffer growing cleanups

Coverity fixes

The `git_buf_init` function has an optional length parameter, which will
cause the buffer to be initialized and allocated in one step. This can
be used instead of static initialization with `GIT_BUF_INIT` followed by
a `git_buf_grow`. This patch does so for two functions where it is
applicable.

Both the `git_buf_init` and `git_buf_attach` functions may call
`git_buf_grow` in case they were given an allocation length as
parameter. As such, it is possible for these functions to fail when we
run out of memory. While it won't probably be used anytime soon, it does
indeed make sense to also record this fact by returning an error code
from both functions. As they belong to the internal API only, this
change does not break our interface.