Fix handling of Specification integration TCKs

We have several instances of specification projects producing TCKs that have dependencies on specifications that are not part of the dependency set of the specification project API artifact. CDI is one such project where integration tests with several downstream projects have integration tests. This complicates the release process of projects like CDI, and the platform/profiles due to these dependencies that complicate the apparent API artifact dependencies.

We need to restructure projects such that TCK integration tests live in some module in the platform TCK project in some integration repository, and all specification committers need to have access to this repository.

The repository should be structured with target integration containers/specifications at the top, and other wave API dependencies as child submodules. For example, there should be a servlet top-level module with submodules like:
+ servlet
- cdi
- jsonp
- rest
- rest-cdi
- security
- security-cdi
- validation

There should be an ejb top-level module with submodules like:
+ ejb
- cdi
- security
- transactions

The number of useful combinations should start with what is required to eliminate circular dependencies in specification projects.

Another aspect of this is that specification requirements associated with the integration tests also need to be part of this repository, and they should be composed into profiles/platform that reference these tests as required.

No files, tests, or entry points are named. Start by mapping the existing specification TCK integration modules and the platform/profile references, then define the repository structure and integration requirements; done means integration dependencies no longer complicate specification API artifacts and required tests are composed into profiles or the platform.

Written by the indexing model from the issue text.