diff_tform: fix rename detection with rewrite/delete pair

A rewritten file can either be classified as a modification of its
contents or of a delete of the complete file followed by an addition of
the new content. This distinction becomes important when we want to
detect renames for rewrites. Given a scenario where a file "a" has been
deleted and another file "b" has been renamed to "a", this should be
detected as a deletion of "a" followed by a rename of "a" -> "b". Thus,
splitting of the original rewrite into a delete/add pair is important
here.

This splitting is represented by a flag we can set at the current delta.
While the flag is already being set in case we want to break rewrites,
we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES`
flag is set. This can trigger an assert when we try to match the source
and target deltas.

Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta
when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is
set.

Add two more scenarios to the "renames" repository. The first scenario
has a major rewrite of a file and a delete of another file, the second
scenario has a deletion of a file and rename of another file to the
deleted file. Both scenarios will be used in the following commit.

While we frequently reuse commit OIDs throughout the file, we do not
have any constants to refer to these commits. Make this a bit easier to
read by giving the commit OIDs somewhat descriptive names of what kind
of commit they refer to.

tests: index::filemodes: fix use of uninitialized memory

The new index entry structure was not being initialized to all-zeroes.
As that structure is used to add a new entry to the current index, and
the hashing algorithm of the index making use of the uninitialized flags
to calculate the state, we might miscompute the hash of the entry and
add it at the wrong position. Later lookups would then fail.

Initialize the structure with `memset` to fix the test breaking on some
platforms.

git_index_add_frombuffer: only accept files/links

Fix build warnings

Ensure that the buffer given to `git_index_add_frombuffer` represents a
regular blob, an executable blob, or a link.  Explicitly reject commit
entries (submodules) - it makes little sense to allow users to add a
submodule from a string; there's no possible path to success.

While "util.h" declares the macro `git__tolower`, which simply resorts
to tolower(3P) on Unix-like systems, the <ctype.h> header is only being
included in "util.c". Thus, anybody who has included "util.h" without
having <ctype.h> included will fail to compile as soon as the macro is
in use.

Furthermore, we can clean up additional includes in "util.c" and simply
replace them with an include for "common.h".

A lot of compilers nowadays generate warnings when there are cases in a
switch statement which implicitly fall through to the next case. To
avoid this warning, the last line in the case that is falling through
can have a comment matching a regular expression, where one possible
comment body would be `/* fall through */`.

An alternative to the comment would be an explicit attribute like e.g.
`[[clang::fallthrough]` or `__attribute__ ((fallthrough))`. But GCC only
introduced support for such an attribute recently with GCC 7. Thus, and
also because the fallthrough comment is supported by most compilers, we
settle for using comments instead.

One shortcoming of that method is that compilers are very strict about
that. Most interestingly, that comment _really_ has to be the last line.
In case a closing brace follows the comment, the heuristic will fail.

Even though the `entry` variable will always be initialized when
`read_entry` returns success and even though we never dereference
`entry` in case `read_entry` fails, GCC prints a warning about
uninitialized use. Just initialize the pointer to `NULL` in order to
shut GCC up.

The strict aliasing rules disallow dereferencing the pointer to a
variable of a certain type as another type, which is frequently used
e.g. when casting structs to their base type. We currently have the
warning level for strict aliasing rules set to `2`, which is described
by gcc(1) as being "Aggressive, quick, not too precise." And in fact, we
experience quite a lot of warnings when doing a release build due to
that.

GCC provides multiple levels, where higher levels are more accurate, but
also slower due to the additional analysis required. Still, we want to
have warning level 3 instead of 2 to avoid the current warnings we have
in the Travis CI release builds. As this is the default warning level
when no level is passed to `-Wstrict-aliasing`, we can just remove the
level and use that default.

When verifying the server certificate, we do try to make sure that the
hostname actually matches the certificate alternative names. In cases
where the host is either an IPv4 or IPv6 address, we have to compare the
binary representations of the hostname with the declared IP address of
the certificate. We only do that comparison in case we were successfully
able to parse the hostname as an IP, which would always result in the
memory region being initialized. Still, GCC 6.4.0 was complaining about
usage of non-initialized memory.

Fix the issue by simply asserting that `addr` needs to be initialized.
This shuts up the GCC warning.

docs: fix typo in "release.md" filename

docs: add release documentation

CHANGELOG: update for v0.27.0

http: standardize user-agent addition

The winhttp and posix http each need to add the user-agent to their
requests.  Standardize on a single function to include this so that we
do not get the version numbers we're sending out of sync.

Assemble the complete user agent in `git_http__user_agent`, returning
assembled strings.

Co-authored-by: Patrick Steinhardt <ps@pks.im>

Plug resource leaks

odb: error when we can't alloc an object

Return an error to the caller when we can't create an object header for
some reason (printf failure) instead of simply asserting.

There's no recovery possible if we're so confused or corrupted that
we're trying to overwrite our memory.  Simply assert.

Provide error messages on hash failures: assert when given invalid
input instead of failing with a user error; provide error messages
on program errors.

It's unlikely that we'll fail to allocate a single byte, but let's check
for allocation failures for good measure.  Untangle `-1` being a marker
of not having found the hardcoded odb object; use that to reflect actual
errors.

At the moment, we're swallowing the allocation failure.  We need to
return the error to the caller.

Streaming read support for the loose ODB backend

Recursive merge: reverse the order of merge bases

config: handle CRLF-only lines and BOM

The function to detect a BOM takes an offset where it shall look for a
BOM. No caller uses that, and searching for the BOM in the middle of a
buffer seems to be very unlikely, as a BOM should only ever exist at
file start.

Remove the parameter, as it has already caused confusion due to its
weirdness.

The function `skip_bom` is being used to detect and skip BOM marks
previously to parsing a configuration file. To do so, it simply uses
`git_buf_text_detect_bom`. But since the refactoring to use the parser
interface in commit 9e66590b (config_parse: use common parser
interface, 2017-07-21), the BOM detection was actually broken.

The issue stems from a misunderstanding of `git_buf_text_detect_bom`. It
was assumed that its third parameter limits the length of the character
sequence that is to be analyzed, while in fact it was an offset at which
we want to detect the BOM. Fix the parameter to be `0` instead of the
buffer length, as we always want to check the beginning of the
configuration file.

Currently, the configuration parser will fail reading empty lines with
just an CRLF-style line ending. Special-case the '\r' character in order
to handle it the same as Unix-style line endings. Add tests to spot this
regression in the future.