Right now, all configuration file backends are expected to
directly mess with the configuration parser's internals in order
to set it up. Let's avoid doing that by implementing both a
`git_config_parser_init` and `git_config_parser_dispose` function
to clearly define the interface between configuration backends
and the parser.

Ideally, we would make the `git_config_parser` structure
definition private to its implementation. But as that would
require an additional memory allocation that was not required
before we just live with it being visible to others.

The config parser code needs to keep track of the current parsed
file's name so that we are able to provide proper error messages
to the user. Right now, we do that by storing a `git_config_file`
in the parser structure, but as that is a specific backend and
the parser aims to be generic, it is a layering violation.

Switch over to use a simple string to fix that.

By convention, parameters that get passed to callbacks are
usually named `payload` in our codebase. Rename the `data`
parameters in the configuration parser callbacks to `payload` to
avoid confusion.

The `parse_section_header_ext` name suggests that it as an extended
function for parsing the section header.  It is not.  Rename it to
`parse_subsection_header` to better reflect its true mission.

When we reach a whitespace after a section name, we assume that what
will follow will be a quoted subsection name.  Pass the current position
of the line being parsed to the subsection parser, so that it can
validate that subsequent characters are additional whitespace or a
single quote.

Previously we would begin parsing after the section name, looking for
the first quotation mark.  This allows invalid characters to embed
themselves between the end of the section name and the first quotation
mark, eg `[section foo "subsection"]`, which is illegal.

When we don't specify a particular column, don't write it in the error
message.  (column "0" is unhelpful.)

Update the configuration parsing error messages to be lower-cased for
consistency with the rest of the library.

Move to the `git_error` name in the internal API for error-related
functions.

While rare and a machine would typically not generate such a configuration file,
it is nevertheless valid to write

    [foo "bar"] baz = true

and we need to deal with that instead of assuming everything is on its own line.