Prioritize CDI Name definition and lookup for Managed Resource

Currently, `@DataSourceDefinition` in common annotations, `@ManagedExecutorDefinition/@ManagedScheduledExecutorDefinition/@ManagedThreadFacotryDefinition/@ContextServiceDefinition` in concurrency, `@JMSConnectionFactoryDefinition/@JMSDestinationDefinition`in messaging, `@BasicAuthenticationMechanismDefinition/@FormAuthenticationMechanismDefinition/@CustomFormAuthenrticationMechanismDefinition/@OpenIdAuthenticationMechanismDefinition` in security, all provides a `name` but it is the JNDI name.

Unfortunately, the support of JNDI naming and lookup in the implementors, eg, Glassfish, OpenLiberty, etc are very different.

Also consider a definition annotation for Persistence unit to apply this pattern, see https://github.com/jakartaee/persistence/issues/701

**Describe the solution you'd like**
As a developer, I hope these definitions accept a CDI valid name as the `name` attribute here, and prefer to use CDI name and CDI container to lookup the resources.

For example:

```java
@DataSourceDefinition(name="bootstoreDs"....)
class DataSourceConfig{}

@ApplicationScoped
class BookRepository{

@Inject @Named("bookstoreDs")
DataSource bookstoreDs;
}
```

Currently, not all of these annotations add `qualifiers` to identify the resources as CDI beans(hope all specifications are aligned with this change).

But convert it to CDI beans by name is more common and acceptable.

Review the listed Jakarta EE definition annotations and the linked Jakarta Persistence issue #701 first. Clarify the proposed CDI-name and CDI-container lookup behavior across the affected specifications, including how resources become CDI beans and what aligned annotation changes would be required; done means the scope and specification changes are agreed.

Written by the indexing model from the issue text.