CI: refactoring

Don't stop on test failures; run all the tests, even when a test fails.

Similar to the way we parse the ctest output on POSIX systems, do the
same on Windows.  This allows us to append the `-r` flag to clar after
we've identified the command to run.

In-memory configuration

Now that we have abstracted away how to store and retrieve config
entries, it became trivial to implement a new in-memory backend by
making use of this. And thus we do so.

This commit implements a new read-only in-memory backend that can parse
a chunk of memory into a `git_config_backend` structure.

Right now, the config file code requires us to pass in its backend to
the config entry iterator. This is required with the current code, as
the config file backend will first create a read-only snapshot which is
then passed to the iterator just for that purpose. So after the iterator
is getting free'd, the code needs to make sure that the snapshot gets
free'd, as well.

By now, though, we can easily refactor the code to be more efficient and
remove the reverse dependency from iterator to backend. Instead of
creating a read-only snapshot (which also requires us to re-parse the
complete configuration file), we can simply duplicate the config entries
and pass those to the iterator. Like that, the iterator only needs to
make sure to free the duplicated config entries, which is trivial to do
and clears up memory ownership by a lot.

Access to the config entries is now completely done via the modules
function interface and no caller messes with the struct's internals. We
can thus completely move the structure declarations into the
implementation file so that nobody even has a chance to mess with the
members.

Instead of directly calling `git_atomic_inc` in users of the config
entries store, provide a `git_config_entries_incref` function to further
decouple the interfaces. Convert the refcount to a `git_refcount`
structure while at it.

The nice thing about our `git_config_iterator` interfaces is that nobody
needs to know anything about the implementation details. All that is
required is to obtain the iterator via any backend and then use it by
executing generic functions. We can thus completely internalize all the
implementation details of how to iterate over entries into the config
entries store and simply create such an iterator in our config file
backend when we want to iterate its entries. This further decouples the
config file backend from the config entries store.

The code accessing config entries in the `git_config_entries` structure
is still much too intimate with implementation details, directly
accessing the maps and handling indices. Provide two new functions to
get config entries from the internal map structure to decouple the
interfaces and use them in the config file code.

The function `git_config_entries_get` will simply look up the entry by
name and, in the case of a multi-value, return the last occurrence of
that entry. The second function, `git_config_entries_get_unique`, will
only return an entry if it is unique and not included via another
configuration file. This one is required to properly implement write
operations for single entries, as we refuse to write to or delete a
single entry if it is not clear which one was meant.

The previous commit simply moved all code that is required to handle
config entries to a new module without yet adjusting any of the function
and structure names to help readability. We now rename things
accordingly to have a common "git_config_entries" entries instead of the
old "diskfile_entries" one.

The configuration entry store that is used for configuration files needs
to keep track of all entries in two different structures:

- a singly linked list is being used to be able to iterate through
  configuration files in the order they have been found

- a string map is being used to efficiently look up configuration
  entries by their key

This store is thus something that may be used by other, future backends
as well to abstract away implementation details and iteration over the
entries.

Pull out the necessary functions from "config_file.c" and moves them
into their own "config_entries.c" module. For now, this is simply moving
over code without any renames and/or refactorings to help reviewing.

The implementation for config file snapshots has an unnecessary
redirection from `config_snapshot` to `git_config_file__snapshot`.
Inline the call to `git_config_file__snapshot` and remove it.

The header "config_file.h" has a list of inline-functions to access the
contents of a config backend without directly messing with the struct's
function pointers. While all these functions are called
"git_config_file_*", they are in fact completely backend-agnostic and
don't care whether it is a file or not. Rename all the function to
instead be backend-agnostic versions called "git_config_backend_*" and
rename the header to match.

The function `git_config_file_normalize_section` is never being used in
any file different than "config.c", but it is implemented in
"config_file.c". Move it over and make the symbol static.

As a last step to make variables and structures more backend agnostic
for our `git_config` structure, rename local variables to not be called
`file` anymore.

Some warnings

index: release the snapshot instead of freeing the index

"warning: values of type 'OSStatus' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat]"

online::clone: free url and username before resetting

Before resetting the url and username, ensure that we free them in case
they were set by environment variables.

git_remote_prune to be O(n  * logn)

Same as with the previous commit, the `file_internal` struct is used to
keep track of all the backends that are added to a `git_config` struct.
Rename it to `backend_internal` and rename its `file` member to
`backend` to make the implementation more backend-agnostic.

Originally, the `git_config` struct is a collection of all the parsed
configuration files from different scopes (system-wide config,
user-specific config as well as the repo-specific config files).
Historically, we didn't and don't yet have any other configuration
backends than the one for files, which is why the field holding the
config backends is called `files`. But in fact, nothing dictates that
the vector of backends actually holds file backends only, as they are
generic and custom backends can be implemented by users.

Rename the member to be called `backends` to clarify that there is
nothing specific to files here.

The variables `git_config_escaped` and `git_config_escapes` are both
defined as static const character pointers in "config_parse.h". In case
where "config_parse.h" is included but those two variables are not being
used, the compiler will thus complain about defined but unused
variables. Fix this by declaring them as external and moving the actual
initialization to the C file.

Note that it is not possible to simply make this a #define, as we are
indexing into those arrays.

When populating the list of submodule names, we use the submodule
configuration entry's name as the key in the map of submodule names.
This creates a hidden dependency on the liveliness of the configuration
that was used to parse the submodule, which is fragile and unexpected.

Fix the issue by duplicating the string before writing it into the
submodule name map.

Rename "VSTS" to "Azure DevOps" and "Azure Pipelines"

cmake: enable -Wformat and -Wformat-security

Visual Studio Team Services is now a family of applications named "Azure
DevOps".  Update the README to refer to it thusly.

VSTS is now a family of components; "Azure Pipelines" is the build and
release pipeline application.

Introduce SKIP_*_TEST variables for Windows builds to match POSIX
builds.

Fix revwalk limiting regression

path validation: `char` is not signed by default.

revwalk: refer the sorting modes more to git's options

Show more directly what the sorting modes correspond to in git's `rev-list` as
that's the reference implementation for what the possible sorting orders are.

We do not currently have any warnings in this regard, but it's good practice to
have them on in case we introduce something.