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.

Upon each line, the configuration parser tries to get either the first
non-whitespace character or the first whitespace character, in case
there is no non-whitespace character. The logic handling this looks
rather odd and doesn't immediately convey this meaning, so add a comment
to clarify what happens.

CMake: minor fixups

Conflict markers should match EOL style in conflicting files

Move the odd code that provides a hierarchical display for projects
within the IDEs to its own module.

Move the nanosecond detection in time structures to its own module.

Enable CMake policy CMP0042, if supported:

> CMake 2.8.12 and newer has support for using ``@rpath`` in a target's
> install name.  This was enabled by setting the target property
> ``MACOSX_RPATH``.  The ``@rpath`` in an install name is a more
> flexible and powerful mechanism than ``@executable_path`` or
> ``@loader_path`` for locating shared libraries.

We can use policy checks to see if a policy exists in cmake, like
CMP0051, instead of relying on the version.

sysdir: do not use environment in setuid case

Consistent header guards

attr: avoid stat'ting files for bare repositories

In order to derive the location of some Git directories, we currently
use the environment variables $HOME and $XDG_CONFIG_HOME. This might
prove to be problematic whenever the binary is run with setuid, that is
when the effective user does not equal the real user. In case the
environment variables do not get sanitized by the caller, we thus might
end up using the real user's configuration when doing stuff as the
effective user.

The fix is to use the passwd entry's directory instead of $HOME in this
situation. As this might break scenarios where the user explicitly sets
$HOME to another path, this fix is only applied in case the effective
user does not equal the real user.

use consistent names for the #include / #define header guard pattern.

Depending on whether the path we want to look up an attribute for is a
file or a directory, the fnmatch function will be called with different
flags. Because of this, we have to first stat(3) the path to determine
whether it is a file or directory in `git_attr_path__init`. This is
wasteful though in bare repositories, where we can already be assured
that the path will never exist at all due to there being no worktree. In
this case, we will execute an unnecessary syscall, which might be
noticeable on networked file systems.

What happens right now is that we always pass the `GIT_DIR_FLAG_UNKOWN`
flag to `git_attr_path__init`, which causes it to `stat` the file itself
to determine its type. As it is calling `git_path_isdir` on the path,
which will always return `false` in case the path does not exist, we end
up with the path always being treated as a file in case of a bare
repository. As such, we can just check the bare-repository case in all
callers and then pass in `GIT_DIR_FLAG_FALSE` ourselves, avoiding the
need to `stat`. While this may not always be correct, it at least is no
different from our current behavior.

Merge example

Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`

Use longer conflict markers in recursive merge base

status::renames: test update for APFS (write NFD instead of NFC filename)

This should have been part of PR #3638. Without this we still get 
nsec-related errors, even when using -DGIT_USE_NSEC:

 error: ‘struct stat’ has no member named ‘st_mtime_nsec’

Special-casing null OIDs

README.md: add notes on how to report security issues

The null OID (hash with all zeroes) indicates a missing object in
upstream git and is thus not a valid object ID. Add defensive
measurements to avoid writing such a hash to the object database in the
very unlikely case where some data results in the null OID. Furthermore,
add shortcuts when reading the null OID from the ODB to avoid ever
returning an object when a faulty repository may contain the null OID.

In commit a96d3cc3f (cache-tree: reject entries with null sha1,
2017-04-21), the git.git project has changed its stance on null OIDs in
tree objects. Previously, null OIDs were accepted in tree entries to
help tools repair broken history. This resulted in some problems though
in that many code paths mistakenly passed null OIDs to be added to a
tree, which was not properly detected.

Align our own code base according to the upstream change and reject
writing tree entries early when the OID is all-zero.

odb: export mempack backend