Add tests to validate more dynamic (advanced) CDI integration use cases

The idea here is to follow up on the topics raised in the discussion of https://github.com/eclipse-ee4j/batch-tck/pull/69 (which we might informally describe as a "pending" TCK challenge, since a formal challenge hasn't been raised at the time of this writing).

It looks though that the `CDITests#testCDILookup` is on its way to getting excluded from the current TCK.
A related follow-up discussion is happening in [this CDI issue](https://github.com/jakartaee/cdi/issues/779) .

From the Batch TCK perspective, what could we add in its place?

Some ideas:

1. The idea in the [PR](https://github.com/eclipse-ee4j/batch-tck/pull/69) of @rzo1 to add a new test app bean to hold the batch property injections, and then validate the non-bean batch artifact can access this via **cdi.select()**, the line `NamedTestBean bean = cdi.select(NamedTestBean.class).get();`
2. Romain's idea described in [comment](https://github.com/eclipse-ee4j/batch-tck/pull/69#issuecomment-1961247625) to get a BeanManager instance via **cdi.select()** from a non-bean, then do
```java
final var creationalContext = beanManager.createCreationalContext(null);
try {
return (String) beanManager.getInjectableReference(new InjectionPoint() {
private final Set qualifiers = Set.of(
new BatchPropertyLiteral(key),
...
```
3. Another idea @Azquelt suggested to me in conversation was to inject an `Instance` , this time into a bean, and to try to do something like this:

```java
@Inject Instance instance;
// then later
instance.select(String.class, new BatchPropertyLiteral("myProperty")).get();
```
The thought was that this too might expose similar gaps or ambiguities, some of which will be discussed in the CDI follow-up issue above.

4. I suppose it's possible that CDI decides the Jakarta Batch test should've worked as it originally was, and OWB ends up supporting it, and we reinstate the test to look like it does currently, like it did in the 2.1 TCK.

### THOUGHTS

I would say we are at liberty to add zero tests, one test, or N tests.. it is up to our judgement what to do or not do here.

Start with CDITests#testCDILookup and the discussion in eclipse-ee4j/batch-tck#69, then review the related Jakarta CDI issue 779. Compare the proposed cdi.select(), BeanManager, and injected Instance scenarios, and determine which cases should be added or whether the existing test should be reinstated. Done means the selected CDI integration cases are implemented as TCK tests with agreement on expected behavior.

Written by the indexing model from the issue text.