Introduce smallrye-config-api module

[gastaldi]

I went ahead with @dmlloyd's suggestion in #981 (comment) and created the Config interface.

This avoids breaking existing code.

/cc @radcortez @dmlloyd

[dmlloyd]

Looks OK to me, as long as we're sticking with methods that were already public and not adding more API. I don't like adding more API - the more API you have, the more "locked in" you are to a design, compatibility-wise.

[radcortez]

Looks OK to me, as long as we're sticking with methods that were already public and not adding more API. I don't like adding more API - the more API you have, the more "locked in" you are to a design, compatibility-wise.

Ok, how about if we keep it empty, and we add the methods we need as we go?

Also, some time ago we discussed about having an api module for this sort of thing. Should we add it now? Other things should definitely go there too, but they need to live on a different namespace like io.smallrye.config.api. Unfortunately, the implementation root is becoming too cramped :(

[dmlloyd]

I'm not so sure about a whole separate module. I think that we are really due for a ground-up rethinking of how this project is put together and consumed. Many of the classes in the implementation module are in fact API, and this project has evolved far beyond the bounds of its original imagining.

Maybe we should go over the list of classes and document approximately how they are used, and maybe try to categorize them, as a starting point. Or have a call where at least the three of us (or more?) talk it through "face to face" and figure out what ought to go where. WDYT?

[radcortez]

I agree. Probably better if we do the categorized work first, and then we can meet to discuss in detail.