Support for including resources files into native images

[lsergio]

This is a proposal for solving #4639. It has been developed with AI assistance and needs further testing.
The idea here is to focus primarily on the documentation of the proposal and check if it sounds reasonable before I invest more time.

(I will be on PTO for a couple of weeks and will review any comments when I come back)

[squakez]

Thanks for the PR. I will give a look asap and provide a detailed feedback. Just a quick consideration though, about the work we'll be doing in #6455 and #6456 which may change the way we generate the project. Ideally we should try to design something which does not affect those parts, for example, only having the logic in the Quarkus trait (if that is even possible).

[squakez]

Thanks for the effort in this PR. Indeed, the change required is quite intrusive and we really appreciate the analysis work.

As I anticipated in my earlier comment, it makes sense that the development of this feature takes in consideration the future architecture of Camel K. The main problem I see here is the file materialization of a generic content, which appears to be really fragile. We must consider the builder pod strategy instead (which will be the only future available strategy).

This strategy is already the only one available when running a Quarkus native image. The rough idea should be that, when a Build resource (potentially configured via builder trait) is found, then the Builder Pod can be mounted with such resource (it could be a configmap or a secret). This materialized file resource can therefore be used as part of the Maven project, via the quarkus.native.resources.includes quarkus trait configuration.

I think this is the best approach and it can go beyond Quarkus Native, being a general feature of the project.