Add default quarkus profile called "native"

[ge0ffrey]

Certain application.properties need to differ between non-native and native runs.
For example:

• in non-native mode it's ok to overwrite and configure optaplanner-accessor-type=REFLECTION, but in native mode, that will crash
• in a demo application, it's ok to use an in memory H2 database (so the user doesn't have to start a database server), but in native mode in memory H2 doesn't work (so the user has to start a database server anyway).

Currently quarkus supports the quarkus profile %prod (and %test). It already uses prod for all native builds (test or not). Resolve native by - for native builds - giving it priority over prod (falling back on prod).

For example, given this application.properties:

alpha=1
beta=1
%prod.beta=2
gamma=1
%prod.gamma=2
%native.gamma=3

• In a dev build: alpha=1, beta=1 and gamma=1.
• In a non-native product build: alpha=1, beta=2 and gamma=2.
• In a native product build: alpha=1, beta=2 and gamma=3.

Clean, simple, intuitive.

[radcortez]

I believe we don't require an extra LaunchMode to support this use case.

The profile used to build the native image can be easily overridden (even as a single maven property in the maven profile that sets up the native build). Multiple profiles can even be used to build the app, and then choose which one to use:
https://quarkus.io/guides/config-reference#multiple-profiles. For instance, it can use a build profile of prod,native, and then the native runtime can provide an application-native.properties to have priority over everything else.

For now, I'm closing this. If there is a use case that the current system is not able to handle, then we can reevaluate.