Don't set entry data when we "get" an entry from the collection, add the
data to the entry before it's put into the collection. This keeps the
entry creation logic in a single place.

The opaque `payload` on an entry is unnecessary and distracting; config
entries should follow the patterns of other objects and use space
elsewhere in the structure with a "base" config entry struct embedded.

A git_config_entry now knows the type of the origin for the entry
("file", "memory", etc) and the path details (for files, the path on
disk). This is propagated through snapshots.

Provide two memory-backed configuration backends -- one that takes a
string in config file format `[section] key=value` and one that takes a
list of strings in `section.key=value` format.

Add a `config` command with `--list` and `--get`.

Introduce `cli_repository_open` which will reparse command-line options
looking for `-c` or `--config-env`. Add those values to an in-memory
configuration database and configure the opened repository with that.

Instead of special casing `--help`, reorder the arguments for
subcommands so that it can handle "global" arguments like `--help`,
`-c key=value`, etc.