Asynchronous repository methods and integration with Jakarta Concurrency

**Description**

As a:

- [ ] Application user/user of the configuration itself
- [x] API user (application developer)
- [ ] SPI user (container or runtime developer)
- [ ] Specification implementer

...I need to be able to:

write repository methods that run asynchronously

...which enables me to:

avoid tying up the requesting thread waiting for queries to finish so that I can complete other work in the mean time.

Note: This issue does not cover reactive programming models like Flow. That is a separate discussion.

The preference would be to rely on the data access provider's own async support, but Jakarta Persistence/JPA (which are JDBC based) doesn't have async support. Lacking that, Jakarta Concurrency [@Asynchronous](https://jakarta.ee/specifications/concurrency/3.0/apidocs/jakarta/enterprise/concurrent/asynchronous) could provide what we need in this area and fit quite well with just some minor language added to the Jakarta Data spec to make it possible.

If we specify that repository methods can have return types of [CompletionStage](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletionStage.html) and [CompletableFuture](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html) (as some implementations already do), then based on the data access provider's level of support for async:
- If the data access provider has its own async support, use that and the stage/future just gets completed with the result upon completion.
- Otherwise, Jakarta Data could state that if a repository interface method is annotated with Concurrency `@Asynchronous` then that same `@Asynchronous` annotation is also applied to the bean instance. Doing that will automatically trigger the Concurrency 3.0 interceptor. Then all the implementation needs to do is return an already-completed future, relying on the Concurrency `@Asynchronous` interceptor to cover making it async.

```
@Asynchronous
CompletionStage> findByNumOrdersGreaterThan(int threshold);

...
findByNumOrdersGreaterThan(2).thenAccept(this::sendLastestSalesPromotion);
```

Other benefits of this will be that if the data access provider, such as based on a Jakarta Persistence/JPA implementation, requires the async thread to have services of the Jakarta EE platform available, such as performing a java:comp/env lookup of a data source, or to be able to run under a transaction, or to have the same security credentials on the thread for performing the database operation, the Jakarta Concurrency spec will have taken care of all of that for us.

Start by reviewing the proposed CompletionStage and CompletableFuture return types, the Jakarta Concurrency @Asynchronous behavior, and the distinction from reactive programming. Done means reaching an agreed specification approach for asynchronous repository methods and documenting how provider-native async support and Jakarta Persistence/JPA implementations should behave.

Written by the indexing model from the issue text.