Downgrade recommended JavaFX version to v19

This is so that the recommended/default JavaFX aligns with the
recommended/default version of Java: currently version 11.

When scijava.jvm.version is increased, we can/should/will also
increase the recommended/default version of JavaFX.

This alignment is necessary for pombast validation checks;
whereas with them misaligned, the javafx components in the
pombast melt dependency graph result in enforcer validation errors:

  [ERROR] Rule 6: org.codehaus.mojo.extraenforcer.dependencies.EnforceBytecodeVersion failed with message:
  [ERROR] Found Banned Dependency: org.openjfx:javafx-media:jar:linux:23.0.2
  [ERROR] Found Banned Dependency: org.openjfx:javafx-swing:jar:linux:23.0.2
  [ERROR] Found Banned Dependency: org.openjfx:javafx-fxml:jar:linux:23.0.2
  [ERROR] Found Banned Dependency: org.openjfx:javafx-web:jar:linux:23.0.2
  [ERROR] Found Banned Dependency: org.openjfx:javafx-base:jar:linux:23.0.2
  [ERROR] Found Banned Dependency: org.openjfx:javafx-controls:jar:linux:23.0.2
  [ERROR] Found Banned Dependency: org.openjfx:javafx-graphics:jar:linux:23.0.2
  [ERROR] Use 'mvn dependency:tree' to locate the source of the banned dependencies.

The reason the javafx components are part of the pombast melt's
dependency graph is because several other included components
(OMEVisual, FilamentDetector, multiview-reconstruction) depend on
javafx, so even with javafx components excluded from the melt
operation's direct dependency graph, they still come in transitively.
We could alternately work around the issue by excluding all the
components depending on javafx, but that would be a hacky
workaround compared to just unifying expectations here.

With this adjustment, errors could now surface in the "other direction":
if a component Foo21 overrides scijava.jvm.version to 21 and
javafx.version to v23, it will be buildable and releasable --
but if that Foo21 component is then added to the pom-scijava BOM,
it will be smelted with JavaFX v19, meaning any too-new API of
JavaFX v23 will not be available, and the Foo21 smelt will fail
accordingly. But this is actually correct: we are asserting that
all versions of components in the BOM actually work together, and
if Foo21 tries to make use of a too-new JavaFX, it *would* fail at
runtime if a downstream component added dependencies on Foo21 and
JavaFX at the BOM's declared versions. So: working as intended!

Author: ctrueden

pom.xml

@@ -2115,7 +2115,7 @@
 		26       | 24
 		27       | 25
 		-->
-		<javafx.version>23.0.2</javafx.version>
+		<javafx.version>19.0.2.1</javafx.version>
 		<javafx-base.version>${javafx.version}</javafx-base.version>
 		<javafx-controls.version>${javafx.version}</javafx-controls.version>
 		<javafx-fxml.version>${javafx.version}</javafx-fxml.version>

pombast.toml

@@ -109,13 +109,6 @@ excludes = [
     'mpicbg:mpicbg', 'mpicbg:mpicbg_',
     # NB: Skip artifacts requiring minimum Java version >11.
     'net.algart:algart-tiff',
-    'org.openjfx:javafx-base',
-    'org.openjfx:javafx-controls',
-    'org.openjfx:javafx-fxml',
-    'org.openjfx:javafx-graphics',
-    'org.openjfx:javafx-media',
-    'org.openjfx:javafx-swing',
-    'org.openjfx:javafx-web',
     'org.morphonets:SNT',
     # NB: Skip closed-source artifacts.
     'org.bonej:bonej-plus',