Fix negative ignore rules with patterns

Submodules with bare repo

-Werror builds for Travis

While it is technically possible to look up submodules inside of a
bare repository by reading the submodule configuration of a specific
commit, we do not offer this functionality right now. As such, calling
both `git_submodule_lookup` and `git_submodule_foreach` should error out
early when these functions encounter a bare repository. While
`git_submodule_lookup` already does return an error due to not being
able to parse the configuration, `git_submodule_foreach` simply returns
success and never invokes the callback function.

Fix the issue by having both functions check whether the repository is
bare and returning an error in that case.

The testcase "submodule::lookup::cached" was declared with a single
underscore separating the test suide and test name, only. As the clar
parser only catches tests with two underscores, it was never executed.
Add in the second underscore to actually have it detected and executed.

When computing negative ignores, we throw away any rule which does not
undo a previous rule to optimize. But on case insensitive file systems,
we need to keep in mind that a negative ignore can also undo a previous
rule with different case, which we did not yet honor while determining
whether a rule undoes a previous one. So in the following example, we
fail to unignore the "/Case" directory:

    /case
    !/Case

Make both paths checking whether a plain- or wildcard-based rule undo a
previous rule aware of case-insensitivity. This fixes the described
issue.

This test is by Carlos Martín Nieto.

Ignore rules allow for reverting a previously ignored rule by prefixing
it with an exclamation mark. As such, a negative rule can only override
previously ignored files. While computing all ignore patterns, we try to
use this fact to optimize away some negative rules which do not override
any previous patterns, as they won't change the outcome anyway.

In some cases, though, this optimization causes us to get the actual
ignores wrong for some files. This may happen whenever the pattern
contains a wildcard, as we are unable to reason about whether a pattern
overrides a previous pattern in a sane way. This happens for example in
the case where a gitignore file contains "*.c" and "!src/*.c", where we
wouldn't un-ignore files inside of the "src/" subdirectory.

In this case, the first solution coming to mind may be to just strip the
"src/" prefix and simply compare the basenames. While that would work
here, it would stop working as soon as the basename pattern itself is
different, like for example with "*x.c" and "!src/*.c. As such, we
settle for the easier fix of just not optimizing away rules that contain
a wildcard.

One of our goals is to have our code free of any warnings. Due to the
recent switch to Ubuntu 14.04 on Travis, the last warning regarding some
preprocessor-magic in the curl-headers has been fixed and as such, the
goal of zero warnings is now reached for Travis CI. In order to avoid
introducing new warnings via pull requests, we can now enable building
with `-Werror` and turn compiler warnings into errors instead, causing
the CI jobs to fail.

This build does so by passing the newly introdcued `-DENABLE_WERROR`
flag to CMake for all Travis jobs.

Add a simple switch to enable building with "-Werror=<warning>" instead
of "-W<warning". Due to the encapsulated `ENABLE_WARNINGS` macro, this
is as simple as adding a new variable "ENABLE_WERROR`, which can be
passed on the command line via `-DENABLE_WERROR=ON`. The variable
defaults to NO to not bother developers in their day to day work.

There are multiple sites where we enable or disable compiler warning via
"-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism
later on to conditionally switch these over to "-Werror=<warning>", we
encapsulate the logic into its their own macros `ENABLE_WARNINGS` and
`DISABLE_WARNINGS`.

Note that we in fact have to use a macro here. Using a function would
not modify the CFLAGS inside of the callers scope, but in the function's
scope only.

Split up CMakeLists.txt build instructions

As observed by Edward Thomson, the libgit2 DLL built by Windows will not
end up in the top-level build directory but instead inside of the 'src/'
subdirectory. While confusing at first because we are actually setting
the LIBRARY_OUTPUT_DIRECTORY to the project's binary directory, the
manual page of LIBRARY_OUTPUT_DIRECTORY clears this up:

    There are three kinds of target files that may be built: archive,
    library, and runtime. Executables are always treated as runtime
    targets. Static libraries are always treated as archive targets.
    Module libraries are always treated as library targets. For non-DLL
    platforms shared libraries are treated as library targets. For DLL
    platforms the DLL part of a shared library is treated as a runtime
    target and the corresponding import library is treated as an archive
    target. All Windows-based systems including Cygwin are DLL
    platforms.

So in fact, DLLs and import libraries are not treated as libraries at
all by CMake but instead as runtime and archive targets. To fix the
issue, we can thus simply set the variables RUNTIME_OUTPUT_DIRECTORY and
ARCHIVE_OUTPUT_DIRECTORY to the project's root binary directory.

With c26ce784 (Merge branch 'AndreyG/cmake/modernization', 2017-06-28),
we have recently introduced a regression in the way we are searching for
headers. We have made sure to always include our own headers first, but
due to the changes in c26ce784  this is no longer guaranteed. In fact,
this already leads the compiler into picking "config.h" from the
"deps/regex" dependency, if it is used.

Fix the issue by declaring our internal include directories up front,
before any of the other search directories is added.

To fix leaking build instructions into different targets and to make
the build instructions easier to handle, create a new CMakeLists.txt
file containing build instructions for the libgit2 target.

By now, the split is rather easy to achieve. Due to the preparatory
steps, we can now simply move over all related build instructions, only
needing to remove the "src/" prefix from some files.

There are quite some uses of the variables "${CMAKE_CURRENT_SOURCE_DIR}"
and "${CMAKE_CURRENT_BINARY_DIR}" where they are not appropriate.
Convert these sites to instead use the variables "${CMAKE_SOURCE_DIR}"
and "${CMAKE_BINARY_DIR}", which instead point to the project's root
directory.

This will ease splitting up the library build instructions into its own
subdirectory.

Extract code required to build the zlib library into its own
CMakeLists.txt, which is included as required.

Extract code required to build the http-parser library into its own
CMakeLists.txt, which is included as required.

Extract code required to build the regex library into its own
CMakeLists.txt, which is included as required.

Extract code required to build the winhttp library into its own
CMakeLists.txt, which is included as required.

This makes splitting up the library build instructions later on more
obvious and easier to achieve.

This makes splitting up the library build instructions later on more
obvious and easier to achieve.

This makes splitting up the library build instructions later on more
obvious and easier to achieve.

Previous to keeping track of libraries and linking directories via
variables, we had two call sites of the `TARGET_OS_LIBRARIES` function
to avoid duplicating knowledge on required operating system library
dependencies. But as the libgit2_clar target now re-uses defined
variables to link against these libraries, we can simply inline the
function.

Later on, we will move detection of required libraries, library
directories as well as include directories into a separate
CMakeLists.txt file inside of the source directory. Obviously, we want
to avoid duplication here regarding these parameters.

To prepare for the split, put the parameters into three variables
LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the
required libraries, linking directory as well as include directories.
These variables can later be exported into the parent scope from inside
of the source build instructions, making them readily available for the
other subdirectories.

When refering to files and directories inside of the top-level "deps/"
directory, we're being inconsistent in using relative or absolute paths.
To enable splitting out parts of the top-level CMakeLists.txt into an
own file in the "src/" directory, consistently switch over to use
absolute paths to avoid errors when converting.

In our CMakeLists.txt, we have to check multiple functions in order to
determine if we have to use our own or whether we can use the
platform-provided one. For two of these functions, namely `regcomp_l()`
and `futimens`, the defined macro is actually used inside of the header
file "src/unix/posix.h". As such, these macros are not only required by
the library, but also by our test suite, which is makes use of internal
headers.

To prepare for the CMakeLists.txt split, move these two defines inside
of the "features.h" header.

In a future commit, we will split out the build instructions for our
library directory and move them into a subdirectory. One of the benefits
is fixing scoping issues, where e.g. defines do not leak to build
targets where they do not belong to. But unfortunately, this does also
pose the problem of how to propagate some defines which are required by
both the library and the test suite.

One way would be to create another variable keeping track of all added
defines and declare it inside of the parent scope. While this is the
most obvious and simplest way of going ahead, it is kind of unfortunate.
The main reason to not use this is that these defines become implicit
dependencies between the build targets. By simply observing a define
inside of the CMakeLists.txt file, one cannot reason whether this define
is only required by the current target or whether it is required by
different targets, as well.

Another approach would be to use an internal header file keeping track
of all defines shared between targets. While configuring the library, we
will set various variables and let CMake configure the file, adding or
removing defines based on what has been configured. Like this, one can
easily keep track of the current environment by simply inspecting the
header file. Furthermore, these dependencies are becoming clear inside
the CMakeLists.txt, as instead of simply adding a define, we now call
e.g. `SET(GIT_THREADSAFE 1)`.

Having this header file though requires us to make sure it is always
included before any "#ifdef"-preprocessor checks are executed. As we
have already refactored code to always include the "common.h" header
file before any statement inside of a file, this becomes easy: just make
sure "common.h" includes the new "features.h" header file first.

Our CMakeLists.txt is very unwieldy in its current size, spanning more
than 700 lines of code. Furthermore, it has several issues regarding
scoping, where for example some defines, includes, etc. from our test
suite are also applied to our normal library code.

To fix this, we can separate out build instructions for our tests and
move them into their own CMakeLists.txt in the "tests" directory. This
reduced complexity of the root CMakeLists.txt file and fixes the issues
regarding leaking build context from tests into the library.

As soon as we split up our CMakeBuild.txt build instructions, we will be
unable to simply link against the git2 library's precompiled header from
other targets. To avoid this future breakage, create a new precompiled
header for our test suite. Next to being compatible with the split, this
enables us to also include additional files like the clar headers, which
may help speeding up compilation of the test suite.

Currently, we're compiling our library code twice, once as part of the
libgit2 library and once for the libgit2_clar executable. Since CMake
2.8.8, there exists a new library type OBJECT, which represents an
intermediate target which can then subsequently be used when linking
several targets against the same set of objects.

Use an OBJECT library to create an internal library for linking. This
new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed
the way how generator expressions are evaluated when accessing
properties, we need to enable CMake policy 0051 to keep
`IDE_SPLIT_SOURCES` functioning.

Once upon a time, the `CLAR_RESOURCES` variable was intended to set
the `CLAR_RESOURCES` define. But actually, the define uses a wrong
variable name by accident, hinting that its value cannot actually be
used at all, as it is empty. Searching through the code base confirms
the guess that the define is not used at all.

Remove both the variable and definition.

While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`,
it is actually undefined due to us never including the "FindThreads"
module in the CMakeLists.txt. It is rather curious as to why this has
never triggered any error up to now, but it does in fact result in
linking errors on some Unix platforms as soon as we split up our build
instructions into multiple files.

Fix the issue now to avoid future breakage by including the
"FindThreads" module.

Include fixups

Docs: Fix inline comments for git_diff_hunk

oid: use memcmp in git_oid__hashcmp