Remove custom key decoders #71
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

Motivation
Implementation PR for a change that will be reviewed in a proposal
Fixes #70
There was a flaw in the design of custom key decoders: if one library changed the key decoder on a ConfigReader, and then passed the ConfigReader to another library, that second library would break, because it was expecting the default dot-based key decoder. This means that at least, ConfigReader is the wrong place for the custom keyDecoder property, and possibly there isn't a good place for it at all.
Modifications
This PR removes the whole concept of custom keyDecoders and hardcodes everything to use the dot-based one. This also unlocks making ConfigKey ExpressibleByStringLiteral, which in turn allows us to remove half of all the method overloads on ConfigReader and friends.
Result
No custom keyDecoder feature. If we find a better to way in the future, we can always introduce it back in an API-stable way. But right now it wasn't pulling its weight.
Test Plan
Adapted tests.