Enhance EE and MP guard rails for feature generation

[TrevCraw]

Currently, we are only checking for EE and MP umbrella dependencies in the pom.xml dependency list to determine the version of EE and MP of the application to then pass to the binary scanner. This is not the most reliable method, and we should look to enhance our ability to detect the EE and MP versions of an application. Below are a few things we can look at to make this detection more robust:

• Feature generation support EE WebProfile umbrella dependency #1591 (as part of this, investigate other umbrella dependencies to use)
• Check for platform element versions in the server configuration #1986
• Investigate POC for determining application version based on EE/MP modular dependencies
• Investigate POC for using the LSP4Jakarta method of determining the EE version
• Provide warnings to users if EE or MP version cannot be found #1987

[turkeylurkey]

To determine the version of Jakarta EE being used we would need to look for one of the following dependencies:
Jakarta EE 9 includes these specifications/modules:

Core Web Profile Specifications:

• Jakarta Servlet 5.0 - HTTP request/response handling
• Jakarta Server Pages (JSP) 3.0 - Dynamic web pages
• Jakarta Expression Language (EL) 4.0 - Expression syntax
• Jakarta Standard Tag Library (JSTL) 2.0 - JSP tag library
• Jakarta Server Faces (JSF) 3.0 - Component-based UI framework
• Jakarta RESTful Web Services (JAX-RS) 3.0 - REST APIs
• Jakarta JSON Processing (JSON-P) 2.0 - JSON parsing
• Jakarta JSON Binding (JSON-B) 2.0 - JSON object mapping
• Jakarta WebSocket 2.0 - WebSocket support
• Jakarta Contexts and Dependency Injection (CDI) 3.0 - Dependency injection
• Jakarta Dependency Injection 2.0 - @Inject annotation
• Jakarta Interceptors 2.0 - Method interception
• Jakarta Annotations 2.0 - Common annotations (@PostConstruct, etc.)
• Jakarta Persistence (JPA) 3.0 - ORM/database access
• Jakarta Transactions (JTA) 2.0 - Transaction management
• Jakarta Bean Validation 3.0 - Validation framework
• Jakarta Managed Beans 2.0 - Managed component model
• Jakarta Security 2.0 - Security APIs

Full Platform Additional Specifications:

• Jakarta Enterprise Beans (EJB) 4.0 - Business components
• Jakarta Messaging (JMS) 3.0 - Message queuing
• Jakarta Connectors 2.0 - Resource adapter architecture
• Jakarta Mail 2.0 - Email APIs
• Jakarta Activation 2.0 - Data type handling
• Jakarta XML Binding (JAXB) 3.0 - XML-Java binding
• Jakarta XML Web Services (JAX-WS) 3.0 - SOAP web services
• Jakarta SOAP with Attachments (SAAJ) 2.0 - SOAP messaging
• Jakarta Web Services Metadata 3.0 - Web service annotations
• Jakarta Batch 2.0 - Batch processing
• Jakarta Concurrency 2.0 - Concurrent utilities
• Jakarta Authorization 2.0 - Authorization framework
• Jakarta Authentication 2.0 - Authentication SPI
• Jakarta Debugging Support for Other Languages 2.0

We would need a table of Jakarta EE versions and for each version we would gather these modules and we would look up the Maven coordinates and add them to the table. Then when analyzing the application we would look up each of its dependencies in the table and make a list of versions of Jakarta EE to which they correspond.

We would need to see if any modules conflicted in terms of the Jakarta version they implied. We'd need to find the maximum version of Jakarta that is implied by the dependencies and make sure all Jakarta dependencies are compatible.