WELD-2810 Add support for sealed classes to the implementation of CDI Lang Model (+ bump to CDI 5.0)

[Ladicek]

JIRA - https://issues.redhat.com/browse/WELD-2810

[Ladicek]

The first commit depends on weld/api#225 and again, doesn't necessarily have to be correct.

The second commit should be good.

[manovotn]

I've sent #3132 to upgrade project version (and similar for API).
Though we'd still need some Alpha releases to avoid the snapshots :)

[manovotn]

I have updated this branch and rebased it onto master so that it has the fix for lifecycle OM and BeanManager param.
It is still running with SNAPSHOT dependencies, so failures are expected.

Though running it locally, I can now see all the tests passing 👍

[Ladicek]

You really should feel free to bump to CDI 5.0 API / Weld 7.0 API elsewhere, if that suits you better. The core value of this PR has always been the implementation of the sealed classes support in the lang model.

[manovotn]

Updated Weld API and CDI TCK versions to newly released Alpha1 versions; moved from draft to ready for review.
CI should now run and provide some meaningful results.

[manovotn]

Uff, these failures are related but I am not sure how much we can do now.

There are calls to BM#getELResolver() which is removed in CDI 5. Now, these calls can be either from WFLY integration code or faces impl, none of which can be easily modified. Even WFLY doesn't yet have a version for EE 11, so none that would reliably operate on CDI 4.1 to have access to the new EL API 🤔

I'll poke around WFLY internals to at least get clarity on what the problems are and create some tracking issue for them...

[manovotn]

Few notes to myself after poking around this today:

• Mojarra has this correctly updated for EE11 version (4.1.x mojarra)
  • Standard WFLY doesn't use this version yet - preview does
    • We could use the preview here and workaround it but it is only a part of the problem
• WFLY internals also need changing
  • There is integration code using BM#getELResolver() and that I cannot change because the codebase is still EE10 based (so no CDI 4.1)
  • Apart from that, many modules will also need to declare deps on CDI EL API as they consume Weld artifacts that now implement it too.

To begin with, we should use the preview WFLY artifact but that does expose other problems such as adding a JMS queue that some tests are using. Apparently, the preview WFLY has different configuration files and the relevant subsystem is no longer pre-configured.
There are some example files that contain the configuration and it seems those work fine. So we either need to setup CI to copy that over or find a way to start WFLY with a custom file that's not in the default dir.

[manovotn]

Ok, this is about as far as I can get with testing it this early (short of building custom WFLY dist) - master is now running against WFLY preview; the script manually patches in CDI 5 and the only culprit is WFLY integration code which won't change unless WFLY switches to EE11 base. As far I as I know that's at least one version away but likely more.

With that in mind, I have added a commit that should disable all WFLY incontainer CI tests for now - they will still show in the CI run overview (as skipped) but won't get in the way.