Move markup code out

[felixfontein]

Start to separate the markup formatting code from antsibull / jinja2 specific code.

I'm currently thinking of separating out a small Python package similar to https://github.com/felixfontein/antsibull-docs-ts/ that can be used by other programs to parse / format Ansible markup, so that not everyone has to reimplement everything.

[felixfontein]

I'm currently thinking of separating out a small Python package similar to https://github.com/felixfontein/antsibull-docs-ts/ that can be used by other programs to parse / format Ansible markup, so that not everyone has to reimplement everything.

@gotmax23 any thoughts about ^? I would probably call that project antsibull-docs-lib and use hatchling instead of poetry. antsibull-docs 2.0.0 can then start using it, the 1.x.y branch should probably keep using its own copy of the code.

[gotmax23]

What projects do you envision as consumers of antsibull-docs-lib? antsibull-docs has a lot of dependencies, so it would be nice to have a smaller library to parse ansible docs especially now that we have more complicated semantic markup.

As for the name, I want to suggest antsibull-docs-core, but I think that's become a cliche at this point. antsibull-docs-lib sounds weird to me though. antsibull-doc-parser is a bit long but it's accurate. Naming is hard.

I agree about limiting this to antsibull-docs v2.

[felixfontein]

Three other projects could use this:

1. https://github.com/ansible-network/collection_prep (I don't think they want to implement it themselves)
2. https://github.com/xlab-steampunk/ansible-doc-extractor (assuming they don't want to implement it by themselves)
3. the validate-modules sanity test in ansible-core (validate-modules: add support for semantic markup ansible/ansible#80243 can be quite simplified when using this parser)

About naming: I'm currently tending to antsibull-docs-parser, it's a bit longer but I think being accurate is more important (in particular since this isn't for end-users).