parent for tck user guides and its adoption

[lukasj]

Fixes Issue
inconsistencies across user guides, wrong section ordering in TOC (it is broken around appendix A in almost all UGs), ability to build on SE 17+ just with maven, maintenance burden when applying fixes to all specs etc

Related Issue(s)
not sure there are any;

Describe the change

• introduce a parent pom for UGs
• parent pom produces 'resources' zip with shared files such as jbake templates, pdf theme, assembly instructions
• each UG:
  • was updated to use that parent
  • reuses "shared" stuff from "resources" zip created by parent
  • obsolete files were deleted
  • has only real content
  • produces jakarta.$specName-tck-user-guide-$version.zip with html and pdf guides

Ideally, the new parent is deployed to maven central, so each UG can (but does not have to) reuse it

this change applies to:

    <modules>
        <module>../connector</module>
        <module>../jacc</module>
        <module>../jaxws</module>
        <module>../jms</module>
        <module>../jpa</module>
        <module>../jsp</module>
        <module>../jstl</module>
        <module>../jta</module>
        <module>../saaj</module>
        <module>../websocket</module>
        <module>../../user_guides</module> <!-- platform -->
    </modules>

Additional context
applying the same change across multiple UGs is just too boring, error-prone, very time-consuming and in the end too expensive

CC @alwin-joseph @anajosep @arjantijms @cesarhernandezgt @dblevins @m0mus @edbratt @gurunrao @jansupol @jgallimore @kazumura @kwsutter @LanceAndersen @bhatpmk @RohitKumarJain @shighbar @gthoman @brideck @OndroMih @dmatej
@starksm64 @scottmarlow

[scottmarlow]

Thanks @lukasj!

[scottmarlow]

to use this change, I think we should:

cd user_guides/parent
mvn clean install

[lukasj]

mvn clean package is enough (and one does not polute his repo with temporary artifacts; the only drawback here is that without install, one has to use mvn -pl :... in order to build submodules

[dmatej]

mvn clean package is enough (and one does not polute his repo with temporary artifacts; the only drawback here is that without install, one has to use mvn -pl :... in order to build submodules

-am and -amd should help with that too ;-)