The idea is the following:
- we collect the config properties and dump them into a file that is
  local to the module - this will help with Develocity caching and a
  lot of other issues.
- ideally the descriptor will be also consumable by IDEs
- when generating the documentation, we will gather all the descriptors
  in the tree and transform them to Asciidoc files.

For now, we keep the old way of doing things around for compatibility.

This is a small change of behavior compared to current, per discussion
with Yoann.

We don't need the annotation processor when compiling the tests.

This should allow us to resolve fully the doc model even if we depend on
classes or config groups that are outside of the scope of the module.
The cost should be negligible and it should simplify things a lot.

All the @ConfigMapping-related annotations in SmallRye Config already
have a runtime retention so it makes sense to be consitent.

Note that we will still need to centralize the Javadoc as obviously the
Javadoc is source only.

Both use traditional config roots AND config mappings at the same time,
which won't be supported in the future.
For now, we try to be lenient as it's going to be a long and bumpy road
to fix it.

Now that we keep all the config annotations at runtime, we can fully
resolve the model from the classpath.
What's missing is the Javadoc but we will collect it in a separate file
and when generating documentation, we will get the associated Javadoc
from that file.

We need more structure than a simple properties.
We keep the .properties for now for compatibility but hopefully we will
be able to drop it in the future.

Noticed thanks to the bug I just fixed.

Personnaly, I would rather ignore them but that's not the current
behavior. See OpenShiftConfig for a good example of it.

-common and -internal will be in the way so let's strip them too.

Also be a little less strict: in the case of config
groups, we only require a Javadoc if it is not a
section.

This is used in Observability Dev Services to share a super interface
between several modules.

We use to generate a gazillion of config groups files and most were
unused.
In the new annotation, we only generate specific files if a section
is marked with @ConfigSection(generated = true).

ConfigSections have to be merged inside a given ConfigRoot. Typically,
HibernateORMConfig has sections that are both in a simple element and in
an unnamed map thus leading to the same section path.

As for ConfigRoots, let's not merge them at all at resolution stage,
given we already do some merging in the Maven plugin,
let's do the merging at the end.

Also drops some code related to having ConfigGroups in the model as we
don't need them.

This is useful in the case of gRPC XDS client config.

This was introduced for Quarkus CXF but it's now also useful for the
very weird core config ConfigRoot.

And make sure we keep the best name when merging the config roots.
This will be useful for the file centralizing all the config doc.

Finally, make sure we have a consistent ordering.

We have one in the classpath and we really don't want it to be executed
so let's disable them.

Using the new model, it's a lot easier to implement.

While we will use <extensions>true</extensions> in the external projects
to simplify the setup, using it in a reactor where the plugin is built
generates a warning.
While it works file, it's less than ideal to have a warning so we
register the plugin manually.

We should have never used the extension processor infra to generate the
Maven plugin reference doc.
This commit makes sure we don't use anything from the annotation
processor.

Also port some of the tests to the new infrastructure.

This should be a lot easier to maintain in the future.

Also adapt sync-web-site.sh to the new structure.

We actually have some level of support for building an extension with
Gradle so we need to make it work.
However, at the moment, it's close to impossible to determine the
extension we are in in a Gradle extension.
So we allow not detecting the extension and disable the config doc
generation in this case.

The annotation processor Filer API doesn't support Windows separators so
let's use a plain string.

I think we need to but it wasn't done before and the website is
apparently not ready for it.
See how https://quarkus.io/version/main/guides/dev-services misbehaves
when all the sections are make searchable.

We need to make sure people will not confuse them in the future.