Add support for non-x86 CPU microarchitectures

[joshuajaharwood]

Fixes #436

Changes:

JavaCV-related changes

• Add dependency on org.bytedeco:opencv-platform and org.bytedeco:ffmpeg-platform.
• Use org.bytedeco.gradle-javacpp-platform plugin - it allows us to specify the CPU architectures we wish to support at build-time with ease. We just support everything by default for now.
• Remove files copied from JavaCV related to frame capture
• Replace commented-out code related to webcam enumeration in UtilOpenCV, add comment explaining why we can't support this as an implementation note in the javadoc itself.
• Close file handles using try-with-resource in UtilOpenCV

Miscellaneous clean-ups:
* Bump spotless plugin to 7.0.2
* Remove deprecated Gradle non-Groovy space-assignment syntax to silence deprecation warnings
* Replace deprecated Gradle Project#buildDir call
* Add java plugin to improve Gradle file syntax analysis in IntelliJ
* General root-level build.gradle tidy-ups
* Upgrade Kotlin plugin version - this should silence Gradle 9 deprecation warnings.
* Add deprecation notice informing users about the danger of using UtilIO.load
(Will move these to new branch)

[lessthanoptimal]

I just glanced at the PR. One immediate comment is that this PR includes both formatting clean up and behavior changes. Could you create a sperate PR for the formatting changes? That one should be approved quickly. Makes it much harder to identify real changes vs simple clean up.

[lessthanoptimal]

To be more specific, put stuff that's in "Miscellaneous clean-ups" into its own PR. Also FYI the generated byte code is Java 11 compatible, but the syntax is java 17. So we should be referencing Java 11 API in JavaDoc since that's what it targets.

[joshuajaharwood]

To be more specific, put stuff that's in "Miscellaneous clean-ups" into its own PR. Also FYI the generated byte code is Java 11 compatible, but the syntax is java 17. So we should be referencing Java 11 API in JavaDoc since that's what it targets.

Yeah, I missed that - I'll correct it

[joshuajaharwood]

I just glanced at the PR. One immediate comment is that this PR includes both formatting clean up and behavior changes. Could you create a sperate PR for the formatting changes? That one should be approved quickly. Makes it much harder to identify real changes vs simple clean up.

OK, I'll revert and cherry pick the misc changes into a separate branch shortly

Latest diff only contains changes relevant to the issue now. Should be easier to review now :)

[lessthanoptimal]

No issues jumped out when visually inspecting the code. I need to try running everything now. Have you done that yourself yet?

[lessthanoptimal]

In the future, try to do these changes in a seperate PR. Besides easier to review, it's easier to debug in the future as you can see the functional changes. Yes I should be more strict about this myself.

[joshuajaharwood]

Ahh, I missed removing this one. I'll pull that out.

[joshuajaharwood]

No issues jumped out when visually inspecting the code. I need to try running everything now. Have you done that yourself yet?

All the OpenCV tests pass on my M1 Macbook Air. I'll run all the tests now and let you know

---

OK, looks like a single test failure:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="boofcv.abst.geo.selfcalib.TestGenerateMetricTripleFromProjective$PracticalGuessAndCheck" tests="3" skipped="0" failures="1" errors="0" timestamp="2025-03-20T15:54:26" hostname="casper.local" time="5.879">
  <properties/>
  <testcase name="perfect_one_camera_minimum()" classname="boofcv.abst.geo.selfcalib.TestGenerateMetricTripleFromProjective$PracticalGuessAndCheck" time="3.017"/>
  <testcase name="perfect_more_than_minimum()" classname="boofcv.abst.geo.selfcalib.TestGenerateMetricTripleFromProjective$PracticalGuessAndCheck" time="1.65"/>
  <testcase name="perfect_three_cameras()" classname="boofcv.abst.geo.selfcalib.TestGenerateMetricTripleFromProjective$PracticalGuessAndCheck" time="1.206">
    <failure message="org.opentest4j.AssertionFailedError: Failed 27 min 2.0 ==&gt; expected: &lt;true&gt; but was: &lt;false&gt;" type="org.opentest4j.AssertionFailedError">org.opentest4j.AssertionFailedError: Failed 27 min 2.0 ==&gt; expected: &lt;true&gt; but was: &lt;false&gt;
	at app//boofcv.abst.geo.selfcalib.CommonGenerateMetricCameraTripleChecks.checkScene(CommonGenerateMetricCameraTripleChecks.java:128)
	at app//boofcv.abst.geo.selfcalib.CommonGenerateMetricCameraTripleChecks.perfect_three_cameras(CommonGenerateMetricCameraTripleChecks.java:85)
	at java.base@17.0.12/java.lang.reflect.Method.invoke(Method.java:569)
	at java.base@17.0.12/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base@17.0.12/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base@17.0.12/java.util.ArrayList.forEach(ArrayList.java:1511)
</failure>
  </testcase>
  <system-out><![CDATA[]]></system-out>
  <system-err><![CDATA[]]></system-err>
</testsuite>

Do you know if this failure's in main's SNAPSHOT, or if it's one I've introduced?

[lessthanoptimal]

I'll look into this in about a week. I've been distracted by preparing for a demo at work.