Cast less blindly between configuration objects

curl: initialize and cleanup global curl state

Instead of treating it as a no-op, treat it as a programming error and return
the same kind of error as if you called to set or delete variables on a
snapshot.

tree: initialize the id we use for testing submodule insertions

win32: strncmp -> git__strncmp for win32 STDCALL

Our curl-based streams make use of the easy curl interface. This
interface automatically initializes and de-initializes the global curl
state by calling out to `curl_global_init` and `curl_global_cleanup`.
Thus, all global state will be repeatedly re-initialized when creating
multiple curl streams in succession. Despite being inefficient, this is
not thread-safe due to `curl_global_init` being not thread-safe itself.
Thus a multi-threaded programing handling multiple curl streams at the
same time is inherently racy.

Fix the issue by globally initializing and cleaning up curl's state.

The win32 C library is compiled cdecl, however when configured with
`STDCALL=ON`, our functions (and function pointers) will use the stdcall
calling convention.  You cannot set a `__stdcall` function pointer to a
`__cdecl` function, so it's easier to just use our `git__strncmp`
instead of sorting that mess out.

Instead of laving it uninitialized and relying on luck for it to be non-zero,
let's give it a dummy hash so we make valgrind happy (in this case the hash
comes from `sha1sum </dev/null`.

When we create an iterator we don't actually know that we have a live config
object and we must instead only rely on the header. We fixed it to use this in a
previous commit, but this makes it harder to misuse by converting to use the
header object in the typecast.

We also guard inside the `config_refresh` function against being given a
snapshot (although callers right now do check).

We use it in a few places where we might have a full object or a snapshot so
move it to where we can actually access it.

We pass this around and when creating a new iterator we need to read the
repository pointer.

Put it in a common place so we can reach it regardless of whether we got a full
object or a snapshot.

Respect core.filemode in checkout

winhttp: enable TLS 1.2

Versions of Windows prior to Windows 8 do not enable TLS 1.2 by default,
though support may exist.  Try to enable TLS 1.2 support explicitly on
connections.

This request may fail if the operating system does not have TLS 1.2
support - the initial release of Vista lacks TLS 1.2 support (though
it is available as a software update) and XP completely lacks TLS 1.2
support.  If this request does fail, the HTTP context is still valid,
and still maintains the original protocol support.  So we ignore the
failure from this operation.

For platforms that do not define `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1`
and/or `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2`.

Include the constants for `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and
`WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2` so that they can be used by mingw.

This updates both the `deps/winhttp` framework (for classic mingw) and
adds the defines for mingw64, which does not use that framework.

travis: use custom libssh2-1-dev package

To avoid pull requests needing to rebase, keep the libssh2-1-dev
package as the development package for libssh2.  Reverting to the
original Debian package structure.

travis: use custom libssh2 package

Use the custom libssh2 package that is a backport of libssh2 1.8.0 to
Ubuntu trusty.

Fixes #4504

Ensure that when examining the working directory for checkout that the
mode is correctly simplified.  Git only pays attention to whether a file
is executable or not.  When examining a working directory, we should
coalesce modes in the working directory to either `0755` (indicating
that a file is executable) or `0644` (indicating that it is not).

Test this by giving the file an exotic mode, and ensuring that when
checkout out a branch that changes the file's contents, that we do not
have a checkout conflict.

Add two tests for filemode.

The first ensures that `core.filemode=true` is honored: if we have
changed the filemode such that a file that _was_ executable (mode 0755)
is now executable (mode 0644) and we go to check out a branch that has
otherwise changed the contents of the file, then we should raise a
checkout conflict for that file.

The second ensures that `core.filemode=false` is honored: in the same
situation, we set a file that was executable to be non-executable, and
check out the branch that changes the contents of the file.  However,
since `core.filemode` is false, we do not detect the filemode change.

We run these tests on both operating systems that obey `core.filemode`
(eg, POSIX) and those that have no conception of filemode (eg, Win32).
This ensures that `core.filemode` is always honored, as it is a cache of
the underlying filesystem's settings.  This ensures that we do not
make assumptions based on the operating system, and honor the
configuration setting even if it were misconfigured.

Add a new branch to the `testrepo` repository, where the `README` file
has changed to executable.  This branch enables typechange tests between
the new `executable` branch and `master`.

v0.27.0-rc1: version bump

checkout: when examining index (instead of workdir), also examine mode

diff_tform: fix rename detection with rewrite/delete pair

When both the index _and_ the working directory has changed
permissions on a file permissions on a file - but only the permissions,
such that the contents of the file are identical - ensure that
`git_checkout` updates the permissions to match the checkout target.

When the working directory has changed permissions on a file - but only
the permissions, such that the contents of the file are identical -
ensure that `git_checkout` updates the permissions to match the checkout
target.

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.

When checking out a file, we determine whether the baseline (what we
expect to be in the working directory) actually matches the contents
of the working directory.  This is safe behavior to prevent us from
overwriting changes in the working directory.

We look at the index to optimize this test: if we know that the index
matches the working directory, then we can simply look at the index
data compared to the baseline.

We have historically compared the baseline to the index entry by oid.
However, we must also compare the mode of the two items to ensure that
they are identical.  Otherwise, we will refuse to update the working
directory for a mode change.

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.