Avoid indexing too many jars at application build time

[gsmet]

We are iterating there quarkusio/quarkus#52880 to understand various large contributions to the build time.

Quarkus CXF was identified as one of the culprits: see quarkusio/quarkus#52880 (comment) .

I had a look at the implementation and it actually makes extensive use of IndexDependencyBuildItem. I first thought it might be only to register classes for reflection (so I tried conditioning all these build steps) but it's a bit more complex than that.

I'm not entirely sure what would be the best strategy but atm, with the current implementation, we are reindexing all these jars at each build.

In Quarkus Amazon Services, we decided to avoid indexing, to hardcode the classes and have a test that checks that the harcoded values are consistent with the index: quarkiverse/quarkus-amazon-services#2016 and quarkiverse/quarkus-amazon-services#2021 .

I'm not entirely sure what the best approach is for Quarkus CXF but I think we should reduce the need for indexing as it makes all builds of applications using Quarkus CXF unnecessary slow.

Happy to discuss the options!