Introduce real link between spec doc and TCK

One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/tck-audit-cdi.xml) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to @SpecAssertion annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/definition/name/NameDefinitionTest.java#L54-L55 for instance).
This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK.
The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating them or at least checking them against the spec.
Since the spec doc is generated with Asciidoctor, this could be done by creating an Asciidoctor macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec.

The immediate benefit I see here would be :

1. make the spec contributors more concerned about TCK
2. reduce the risk of forgetting rules in TCK
3. produce a version of the spec with links to TCK test
4. reduce the fear of refactoring the spec if needed

To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality.