Evaluate how we can fully support fa(s)t-jar execution

While working on #5488 I realized we have certain limitations/assumptions in the way we require to execute the jvm from the Camel application container Pod. It turns out that, due to the usage of Joor and its limitations (see [1]) we cannot make a reliable usage of the fast-jar (and eventually fat-jar if/when we move to managed Springboot).

I think the root cause is coming from the fact that we're loading the routes dynamically, ie, we create a generic project, and at runtime we inject the route into the Camel context and start it (please, @lburgazzoli correct me if this is wrong). This was a cornerstone of the reusability of an IntegrationKit which spared some time to build a new project. However, I wonder if this is a design we still want to maintain as it gives us certain limitations, and, remove the parity between a normal Camel (Quarkus) development and Camel K.

If we instead let the build to consider the route at runtime, we should be able to use the fa(s)t-jar and leverage the default Camel mechanism to load a route. Of course, the trade off is that we would be losing the possibility to reuse the same IntegrationKit for different Integrations as, each of them would be including the route into the build. We should understand if this design can still be compatible with incremental image [2] (I think it does, since the route would be contained in the built dependency which is going to be replaced in the new Kit created).

This is something to address in a major release, as it would break existing Integrations compatibility, but I think that it is a good opportunity to collect feedback to be ready when this is coming.

[1] https://github.com/jOOQ/jOOR/issues/69
[2] https://camel.apache.org/camel-k/next/architecture/incremental-image.html

Start by reviewing the Joor limitation in [1] and the incremental image architecture in [2]. Compare the current runtime route-loading approach with fast-jar and fat-jar execution, then document whether the alternatives preserve incremental images and what compatibility trade-offs a major release would require.

Written by the indexing model from the issue text.