conf.d-style loading of a bag of files

One of the things discussed with the [downstream](https://github.com/jupyter/notebook/pull/879) is a [conf.d](https://lists.debian.org/debian-devel/2010/04/msg00352.html)-style loading of a directory of files, probably put there by a package manager (at least, not put there by an application itself).

It could live here. This would have the benefit of making all ConfigManager downstream implementations able to use this feature. There would also be the question of whether one could silently add this.

If it lived here, it looks like it would have to be reflected in:
- a FileConfigLoader subclass
- a BaseJSONConfigManager

> **Question** Why do both of these even exist?

For example, in the notebook, this would entail loading and merging the following files:
- `[sys.prefix | /usr/local | ~)/jupyter/
- `jupyter_notebook_config.json.d/`
1. some_thing.json
2. some_other_thing.json
- `jupyter_notebook_config.json`

When writing in both those files, when a config is _written_, it can only write to the "non-.d" location. Further, it shouldn't write out the whole shooting match (of all the `.d/*` files), but only the novel, unique data introduced by the user. so:

```
conda install nbpresent
jupyter nbextension disble --py some_other_extension
```

shouldn't store the nbpresent data in the config. This suggests we may need some kind of "taint checking" to know whether a value should be persisted or not.

Start by reading the FileConfigLoader and BaseJSONConfigManager areas mentioned in the issue, then review the linked downstream discussion. Define how files in a .d directory are discovered and merged, and how writes preserve only user-introduced data in the non-.d location. Done means the loading and persistence behavior is specified and covered for downstream ConfigManager implementations.

由索引模型根据 Issue 内容生成。