Config Doc - Support more features in Asciidoc -> Mardown converter

[gsmet]

While I implemented a first version of an AsciiDoc -> Markdown converter here: #42677 (see specific commit introducing the asciidocToMarkdown method in JavadocToMarkdownTransformer), there are still features that we need to support...

A good example of what we need is in the https://quarkus.io/guides/hibernate-search-orm-elasticsearch#configuration-reference-main where Yoann had a lot of fun.

• Ideally, we would need to support some of the Asciidoc attributes such as {hibernate-search-docs-url}. They would have to be obtained from the Maven properties as they are currently defined there and we want to be consistent.
• We would have to support the dt/dd constructs:

`simple`::
The default, future-proof strategy: if the index name in Hibernate Search is `myIndex`,
this strategy will create an index named `myindex-000001`, an alias for write operations named `myindex-write`,
and an alias for read operations named `myindex-read`.
`no-alias`::
A strategy without index aliases, mostly useful on legacy clusters:
if the index name in Hibernate Search is `myIndex`,
this strategy will create an index named `myindex`, and will not use any alias.

• We would have to support tables (note that they are not using the usual | marker so we would have to support whatever is there):

[cols=5]
!===
.2+h!Strategy
.2+h!Throughput
3+^h!Guarantees when the application thread resumes

h!Changes applied
h!Changes safe from crash/power loss
h!Changes visible on search

!async
!Best
^!icon:times[role=red]
^!icon:times[role=red]
^!icon:times[role=red]

!write-sync (**default**)
!Medium
^!icon:check[role=lime]
^!icon:check[role=lime]
^!icon:times[role=red]

!read-sync
!Medium to worst
^!icon:check[role=lime]
^!icon:times[role=red]
^!icon:check[role=lime]

!sync
!Worst
^!icon:check[role=lime]
^!icon:check[role=lime]
^!icon:check[role=lime]
!===

Given the complexity of these tables, we won't be able to render them as plain Markdown tables so they will have to be rendered as HTML. We might not be able to render all the subtleties in Markdown (typically not sure if we can center things when using HTML in Markdow...).
It should be rendered as:

• And given what I just pasted, we would have to translate some of the icons too.

And probably more to follow...

[quarkus-bot]

/cc @radcortez (config)

[gsmet]

FWIW, I think it might be a good first issue as it's really tied to the core/processor module and might be easier with some AI help.

[gsmet]

@ppalaga it would be helpful if you could have a look at what I did here: 10ffdcb and add more things that we need to support.

[ppalaga]

Thanks for the heads up, @gsmet. I wonder whether you have any good method to validate the output for a given extension? My understanding is that it is supposed to output some structured output for IDEs. Are there some (which) IDEs supporting that format already? Do I need some specific IDE plugin to view the rendered config property docs?

[gsmet]

I was told IDEs support Markdown so the goal is to output some not too clever Markdown. I have no actual way to validate what I output. I'll discuss with the IDE people once I have some reasonable examples.

[ppalaga]

Exactly: knowing how to view the config docs in an IDE would allow me to figure out whether the output (e.g. for QCXF) makes any sense.

[Saurabhyadav0]

hello @gsmet i am new to this open source contribution can you guide me