Allow override of compiler flags

[osialr]

• Rework compiler properties to allow overriding the defaults with debug flags
• Add noexec flag to jni libraries to remove JVM warning

Reasoning
I needed to add lower optimization levels but the -O3 was inserted last and override my choice. This makes the default property always included and appends on any other compiler options.

Note
Tested on linux-x86_64, windows-x86_64, windows-x86, and mac-x86_64. I couldn't test other platforms

[saudet]

We can't always have the default included because flags like -march=armv5te and -march=armv7-a are mutually exclusive...

[osialr]

I'll have to think about how to best approach it. I included default to avoid breaking existing code.

It does seem odd to me that a different architecture is buried inside a fastfpu option. I could special-case Builder so that doesn't include default if fastfpu is set and platform is android-arm.

[saudet]

The idea was that the user could manually reinclude "default" if it was required for build. Leaving it the way it was shouldn't break any existing code ...Do you have an example?

[osialr]

Looking through the javacpp-presets, most @Platforms don't specify compiler= at all. Those that do rarely have compiler={"default", ...}. Only the avutil preset included default

By splitting platform.compiler.output, and not including default, most of the libraries would not have the same compiler flags.

Here's an idea: what if the resource files were left as-is the same but platform.compiler.output was placed first, then all other platform.compiler.* afterwards?

[saudet]

Putting platform.compiler.output first would only get us something when the compiler prioritizes the last options specified on the command line. I know GCC works that way, but I don't think that's how cl.exe works, or does it?

I like the idea of having "debug" and "release", that's fine, but we somehow need to keep the current functionality working, in this case, on the android-arm platform, that's all.

[osialr]

CL should have the same behavior as gcc

CL
Compiler options are processed "left to right," and when a conflict is detected, the last (rightmost) option wins

gcc
If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.

[saudet]

Right, but now I remember, everything after /link has to be linker related options. It's a lot more complicated than it looks.

BTW, I believe "debug" and "release" should be builder options. It might make things easier to think of them that way too, but I'm not too sure about how this should all work. I'm open to proposals.

[saudet]

FWIW, for projects that require more powerful C++ build options, I recommend generating the source code with -nocompile and use it with CMake. Gradle is starting to look interesting too:
https://docs.gradle.org/current/userguide/native_software.html
But "Mingw-w64 is currently not supported." Bummer :(

[saudet]

I've finally figured out what to do about this: Allow users to disable the "default" options. Specifically, with @Platform(compiler="!default", ...). Other than that, I've basically replicated this PR in the commit above, but without changing the options too much. Let's not fix what isn't broken. :) If you have a reason to change these options though, please send another PR for that! Thanks for your time on this. It is very appreciated.