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

The opaque `payload` on an entry is unnecessary and distracting; configentries should follow the patterns of other objects and use spaceelsewhere 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 ondisk). This is propagated through snapshots.

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

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

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

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