Introduce the logical concept of a worktree-level config.  The new
value sits between _LOCAL and _APP to allow `git_config_get_*` to
'just work'.

The assumption of how `git_config_get_*` works was tested
experimentally by setting _WORKTREE to some nonsense value (like -3)
and watching the new test fail.

Now that GIT_CONFIG_LEVEL_WORKTREE exists logically, define and load
$GIT_DIR/config.worktree into that level.

Now that worktree-level configuration can be read from disk and
manipulated in memory, we should be able to say we support
'extensions.worktreeConfig'.

This structure provides for cleaner diffs in upcoming commits.

It would seem that `get_backend_for_use` is primarily used when
writing config data -- either to set keys or delete them (based on the
possible values of `backend_use`). When git-config(1) is used for
side-effects, it will modify only the local (repository-level)
configuration unless explicitly overridden.

From git-config(1):

    --local
        For writing options: write to the repository .git/config file.
	This is the default behavior.

`get_backend_for_use` does not have the ability to specify a config
level and typically is expected (it seems) to 'do the right thing'.
Taking its cue from git-config(1), don't update worktree-specific
config unless it's the only option.

If that functionality is needed by consumers, I assume they would find
the appropriate backend with `git_config_open_level` and feed that
`git_config` object through to the `git_config_set_*` functions (as
demonstrated in the provided test).

When deleting a key from a repository with multiple config
backends (like a --local config and a --worktree config), it's
important to return the correct backend to modify.

This patch ensures that we don't return a backend that is incapable of
deleting a given piece of configuration when that is the required use.

Before passing the config key name to backend->get(), it needs to be
normalized first. Not all current callers are performing this
normalization, so perform it centrally instead.

Co-authored-by: Brian Lyles <[email protected]>

This looks like a simple copy/paste error.

Now that get_backend_for_use can return other error codes (by virtue
of key-name normalization), make sure to propagate the appropriate
error code when used.

`cl_git_fail_with` is preferred over asserting a return value; the
former gives more detailed information about the mismatch.

Configuration read order and write order should be separated. For
example: configuration readers have a worktree level that is higher
priority than the local configuration _for reads_. Despite that, the
worktree configuration is not written to by default.

Use a new list, `writers`, to identify the write target.

To do this, we need another level of indirection between backend
instances (which are refcounted and shared amongst different git_config
instances) and the config reader/writer list (since each of those
different git_config instances can have different read/write
priorities).

Introduce `GIT_EREADONLY` and return it when a read-only configuration
is attempted to be mutated. This is preferred over the prior
`GIT_ENOTFOUND` which is not accurate.

When a configuration transaction is freed with `git_transaction_free` -
without first committing it - we should not `git_config_free`. We never
increased the refcount, so we certainly shouldn't decrease it.

Also, add a test around aborting a transaction without committing it.

When we `git_config_unlock`, we shouldn't _unlock the thing that we
locked_ instead of assuming that the highest-priority target _remains_
the highest-priority target.

When we start a transaction, we should refcount the backend so that we
don't lose it. This prevents the case where we have a transaction open
and a configuration entry locked and somebody forces a new backend at
the same level and the backend is freed. Now a user can gently wind down
their transaction even when the backend has been removed from the live
configuration object.

Only read the worktree configuration when `extensions.worktreeconfig` is
set to true.

Instead of reading the worktree configuration from the commondir, read
it from the gitdir. This ensures that each worktree gets its own
configuration.