Improve build system's handling of native classifier dependencies

[ctrueden]

The scenery project currently depends on gluegen+jogl (jogamp), ffmpeg (javacpp), and lwjgl, all of which have native library dependencies bundled into JAR files, which are published with classifiers for each platform named according to various conventions. For completeness, the matrix is as follows:

OS	Arch	LWJGL	FFMPEG	JogAmp
Windows	x86-32	natives-windows-x86	windows-x86	-
Windows	x86-64	natives-windows	windows-x86_64	natives-windows-amd64
Windows	arm64	natives-windows-arm64	-
macOS	x86-64	native-macos	macosx-x86_64	natives-macosx-universal
macOS	arm64	native-macos-arm64	macosx-arm64	-
Linux	x86-32	-	linux-x86	-
Linux	x86-64	natives-linux	linux-x86_64	natives-linux-amd64
Linux	arm32	natives-linux-arm32	-	-
Linux	arm64	natives-linux-arm64	linux-arm64	natives-linux-aarch64
Linux	armhf	-	linux-armhf	natives-linux-armv6hf
Linux	ppc64le	-	linux-ppc64le	-
Android	arm	-	android-arm	-
Android	arm64	-	android-arm64	natives-android-aarch64
Android	x86-32	-	android-x86	-
Android	x86-64	-	android-x86_64	-

As you can see, each has its own naming conventions. What we really want is for downstream consumers of scenery and/or sciview to automatically inherit the correct native classifier dependency for their platform, as long as one exists. @elect86 pointed out Gradle's way of handling native classifiers (see also this LWJGL issue). But scenery and sciview are not currently using this approach for their native-classifier dependencies. But currently, scenery and sciview hardcode the list of native classifiers, and expose all of them downstream, regardless of platform. It would be nice to avoid this, to minimize the downstream dependency footprint.

For what it's worth, the way SciJava deals with this is that pom-scijava-base defines a few general-purpose native classifier <properties> that get populated by <profiles> keyed on each supported operating system family and architecture. And then in the pom-scijava BOM, more project-specific properties are defined for javacpp components and for jogamp components, and <dependency> blocks in <dependencyManagement> manage those components with classifiers aligned with those properties (e.g. javacpp deps).

The nice thing about the SciJava way using Maven is that you just add one dependency block to the native classifier using the property, without worrying about enumerating the architectures—no case logic needed downstream. And consumers can override the property if their architecture doesn't match the built-in ones, to grab whichever native classifier they want. The downside is that Maven doesn't fully understand the relationship between these dependencies, unlike the Gradle-based solution linked above, so you do have to declare that one dependency block—better would be if simply depending on e.g. org.lwjgl:lwjgl automatically brought in the correct native classifier artifact as a dependency for the consumer's platform, hassle-free. IIUC, the Gradle docs linked above describe how to do this successfully using the Gradle Metadata Model, but I'm far from expert...

At minimum, I think we want to reach a point where depending on scenery does not inflict any dependencies on any native classifier JARs of non-matching platforms.