Place json configuration files next to thin jar when building

[geoand]

This makes it very easy and predicable to configure
add extra json files to configure GraalVM natives.
Furthermore, this makes these files available to
docker when a container build of the native image
is being used - something which fails without this change.

Fixes: #5390

[geoand]

I could add tests for these if you feel it's warranted, but they would of course slow down the build a lot.
I tested by creating a maven and gradle project then adding a json config file for GraalVM and finally building using both regular and docker builds.

[gastaldi]

Added some comments

[gastaldi]

LGTM

[geoand]

@gsmet are you ok with this one?

[stuartwdouglas]

I don't really like this solution. Even though it improves the status quo I still don't think it provides a great user experience.

Maybe the approach should be:

• Everything in the application (src/main/resources) is included by default (otherwise why would it be in the application if it was not needed?)
• Additional resources can be included through either an annotation that specifies the paths to include, or a config file in a well known location (quarkus-resources.properties?) that we parse at build time and then automatically handle.
• Maybe the ability to include resources via application.properties, but I don't know if this is really config

I think we should discuss this, as the user should not have to mess around with JSON files or the substrate command line to include some resources in their image.

[geoand]

@stuartwdouglas you have my vote when it comes to adding everything in src/main/resources, I had even opened an issue about it: #2746.

This PR didn't really attempt to solve that problem generally. It was motivated primarily by the fact that currently one can't due a native build using docker and specify the json config files

[geoand]

Even if we do add some dedicated configuration options for resource and reflection handling (plus whatever other json file could be added), we'll still need the copy mechanics of this PR.

I do like the idea of having dedicated quarkus.native.reflection-config-files or something like that to users can just specify what they want to include.