The code appending new configuration entries to our current list first
allocates the `cvar` structure and then passes it to `append_entry`. As
we want to extend `append_entry` to store configuration entries in a map
as well as in a list for ordered iteration, we will have to create two
`cvar` structures, though. As such, the future change will become much
easier when allocation of the `cvar` structure is doen in `append_entry`
itself.

In order to reject writes to included configuration entries, we need to
keep track of whether an entry was included via another configuration
file or not. This information is being stored in the `cvar` structure,
which is a rather weird location, as it is only used to create a list
structure of config entries.

Move the include depth into the structure `git_config_entry` instead.
While this fixes the layering issue, it enables users of libgit2 to
access the depth, too.

The `cvar_t` structure is really awkward to grasp, because its name
actively hinders discovery of what it actually is. As it is nothing more
than a singly-linked list of configuration entries, name rename it to
just that: `config_entry_list`.

The interface for freeing config list entries is more tangled than
required. Instead of calling `cvar_free` for every list entry in
`free_vars`, we now just provide a function `config_entry_list_free`.
This function will iterate through all list entries and free the
associated configuration entry as well as the list entry itself.

The struct `parse_data` sounds as if it was defined and passed to us
from the configuration parser, which is not true. Instead, `parse_data`
is specific to the diskfile backend parsing logic. Rename it to
`diskfile_parse_state` to make that clearer. This also follows existing
naming patterns with the "diskfile" prefix.

The config file parsing code all revolves around the `refcounted_strmap`
structure, which is a map of entry names to their respective keys. This
naming scheme made grasping the code quite hard, warranting a rename. A
good alternative is `diskfile_entries`, making clear that this really
only holds all configuration entries.

Furthermore, we are about to introduce a new linked list of
configuration entries into the configuration file code. This list will
be used to iterate over configuration entries in the order they are
listed inside of the parsed configuration file. After renaming
`refcounted_strmap` to `diskfile_entries`, this struct also becomes the
natural target where to add that new list. Like this, data structures
holding all entries are neatly contained inside of it.

Currently, we only parse the entry map into `append_entry` to append new
configuration entries to it. Instead, though, we can just pass the
complete `diskfile_entries` structure into it. This allows us to easily
extend `diskfile_entries` by another singly linked list of configuration
entries.

Right now, we only keep all configuration entries in a string map. This
is required to efficiently access configuration entries by keys. It has
the disadvantage of not being able to iterate through configuration
entries in the order they were read, though. Instead, we only iterate
through entries in a seemingly random order.

Extend `diskfile_entries` by another list holding configuration entries.
Like this, we maintain all entries in two data structures and can use
the required one based on the current use case.

Currently, all configuration entries were only held in a string map,
making iteration order mostly based on the hash of each entry's key. Now
that we have extended the `diskfile_entries` structure by a list of
config entries, we can effectively iterate through entries in the order
they were added, though.