Consider removing custom keyDecoders

[czechboy0]

Since adopters can create a copy of ConfigReader with a different keyDecoder, they can also pass it to another library, which might be expecting the default keyDecoder - so calls to most methods that take a String won't work correctly. This presents a challenge.

What should the story be here? Should we reconsider custom keyDecoders completely, and always use a dot-based decoder? That'd mean adopters with custom conventions who want to pass a multi-component key would need to create AbsoluteConfigKey manually (eg using the array literal of components). That might be okay.

[czechboy0]

If we do this, we can make ConfigKey ExpressibleByStringLiteral and remove half of all the generated overloads!