Improve config subsystem

CouchDB's configuration subsystem is fragile, presents deployment issues for packaging and containers, and needs to be reworked.

_Numbers in "Expected Behaviour" below match up with the same number under "Current Behaviour."_

## Expected Behaviour
1. Single place for server admins to go to change server settings in the filesystem
1. Single place for developers to define default values for config settings, checked into source control
1. Default values can be fed into documentation
1. A way to separate out package/distribution-specific changes from local admin-specific changes; i.e., a package or container update should never have conflicting changes with local admin-introduced changes
1. On API-based config updates, the definition of the config should be changed where it's made, not in the last file in the config chain

## Current Behaviour
1. Mix of `vm.args`, `local.ini`, `local.d/*.ini`, unsanctioned changes to `default.ini` and `default.d/*.ini`, `sys.config`, `.erlang`, `.erlang.cookie`, ...
1. Default values are scattered throughout the code, wherever we invoke `config:get/3`
1. Documentation lags behind implementation and is only updated when someone notices, remembers, or files a bug, meaning we potentially have forever-wrong content out on docs.couchdb.org
1. `default.d/*.ini` and `local.d/*.ini` actually works OK, but is a bit obscure; even after marking `local.ini` as a config file in the `.deb` package we still get reports like #1594
1. Only the last file in the config change is ever updated when modifying the config via the HTTP API, see #777 - note that some such as @rnewson really like this behaviour for reasons such as automated configuration deployment

## Possible Solution
Up for discussion...

One option:
* Remove `default.ini` and `local.ini` entirely.
* Rename `default.d` and `local.d` into something that indicates the contents of `default.d ` are considered by CouchDB as read-only, and `local.d` are read-write. The former is used by packages, the system, containers, ansible/puppet/chef/etc for laying down invariant config files. The latter is used for local modifications and anything that comes in via the HTTP API.
* Define config settings in a per-module fashion in something similar to `stats_descriptions.cfg` that includes the setting, a short description, and the default value.

## Context
Everything under "Current Behaviour" above represents a problem I, or someone else on the CouchDB dev team, have run into.

Start by mapping the current configuration flow across vm.args, local.ini, local.d/*.ini, default.ini, default.d/*.ini, sys.config, and .erlang. Read the related context in issues #1594 and #777. Done would require an agreed design and coordinated changes that provide the five expected behaviours, but this issue does not yet define a specific implementation or tests.

Written by the indexing model from the issue text.