Integrate with config front-end in ZIO 2.0.4

[jdegoes]

ZIO 2.0.4 provides a config front-end, which can be used to describe the format of configuration data.

ZIO Config should integrate cleanly into this configuration front-end, providing the ability to supply ConfigProvider for the front-end, as well as declaratively specify how multiple, disparate, disjointed or maybe even overlapping configuration sources collectively provide all of the configuration requirements of the application.

Several points of integration must be determined:

1. Should zio.Config replace ConfigDescriptor, or should it be possible to derive zio.Config from ConfigDescriptor?
2. If we delete ConfigDescriptor, how does this affect read, document, generateReport, and write?
3. Do we need ConfigSource, or can we instead use the ConfigProvider, maybe in a layer?
4. What does the user interface look like for using ZIO Config providers?
5. Can ZIO Config derive Config from data types, just like it can now derive ConfigDescriptor from ADTs?

[vagroz]

It would be nice to have an interop with pureconfig's ConfigReader.

[jdegoes]

@afsalthaj and I discussed the following plan:

1. Remove everything in zio.config._, except for the documentation part, which can be retrofitted to work with zio.Config and zio.ConfigProvider.
2. Refactor integrations to use Config instead of ConfigDescriptor, and ConfigProvider instead of ConfigSource.
3. Possibly, add missing methods to zio.ConfigProvider or zio.Config.
4. Refactor each integration into a layer ZLayer[Any, Nothing, Unit], which installs its config provider. So, for example, the hocon integration would expose a layer that can be incorporated into an app to install the HOCON config provider.
5. Release this as ZIO Config 4.0.0.