Assignability of raw and parameterized types for type variables with multiple bounds (CDI-440)

I happened to notice that [CDI-440](https://issues.redhat.com/browse/CDI-440) does not seem to have any resolution in the current version of the CDI specification.

Following the rules in the [Jira issue](https://issues.redhat.com/browse/CDI-440?focusedId=16201596&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16201596), which read:

> The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in [this GitHub issue](https://github.com/eclipse-ee4j/cdi/issues/479).
> If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.
> For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
> For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues

…I am filing this issue to resurrect CDI-440.

The original issue reads:

> Rules defined in section '~5.2.4.~ [[2.4.2.4]](https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#assignable_parameters) Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds.
>
> For example, the bullet
>
> > the required type parameter and the bean type parameter are both type variables and the upper bound of the required type parameter is assignable to the upper bound, if any, of the bean type parameter.
>
> should have meaning similar to:
>
> ... for each upper bound T of the bean type parameter, there is an (at least one) upper bound of the required type which is assignable to T.
>
> Consider the following example:
> - interfaces Bar, Baz, Foo
> ```
> class BarImpl implements Bar { ... }
> interface MyInterface { ... }
> ```
> - bean:
> ```
> class MyBean implements MyInterface { ... }
> ```
> - injection point:
> ```
> class TestClass {
> @Inject
> MyInterface bean;
> }
> ```
> MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected.
>
> Please, correct me if I am wrong.

[A comment](https://issues.redhat.com/browse/CDI-440?focusedId=12971889&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12971889) indicates that this interpretation would seem to be correct, but it [was never adopted](https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#assignable_parameters).

There is a [related issue](https://issues.redhat.com/browse/WELD-1684) that indicates that Weld adopted and implemented this unofficial interpretation.

[The TCK appears to perhaps enforce this unofficial interpretation](https://issues.redhat.com/browse/CDITCK-414) as well.

I'm not sure the suggested language is exactly correct, but the spirit of it seems correct.

Start with CDI specification section 2.4.2.4, then compare the CDI-440 examples with the related Weld-1684 and CDITCK-414 issues. The issue needs an agreed interpretation of multiple type-variable bounds and precise specification language; done means the specification decision is adopted and any affected TCK behavior is addressed.

Written by the indexing model from the issue text.