chore: Move to a gradle version catalog and treat mockito dynamic agent loading

[SomeTroglodyte]

Related: #13242

We shouldn't allow ourselves to get irrevocably used to see this RED wall of text when running any unit test:

WARNING: A Java agent has been loaded dynamically (/home/bob/.gradle/caches/modules-2/files-2.1/net.bytebuddy/byte-buddy-agent/1.15.0/e32740c43acebaac9d55b86399ecf6a5df3c17fb/byte-buddy-agent-1.15.0.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release

... so let's cure it.

With a fresh mockito you get one extra line, linking to https://javadoc.io/doc/org.mockito/mockito-core/latest/org.mockito/org/mockito/Mockito.html

And since that example relies on having a gradle version catalog, I've migrated our gradle monster to one.

Notes:

• I would have preferred a settings.gradle.kts based catalog, and I've tried. Android Studio really didn't like that, it prefers the archaic TOML.
• Kludge One, Gdx natives have an ID format the catalog doesn't support directly - I've cataloged the 'platform' part and build the rest with a helper function.
• Kludge Two, the automatic identifier libs should simply be available - and with tons of luck you can have uses in a subproject within the root build.gradle.kts that works. Change something unrelated and gradle bombs unintelligible exceptions. Saving libs into another val at root level and using that instead perversely works, but I preferred the rootProject.libs workaround - mainly 'cuz I had no idea what to name that val. Regrettably, that breaks a small part of Studio's support - e.g. if you follow an inspection telling you to use a catalog entry or to create one, the result often needs re-applying the kludge or it won't sync. But overall I believe this is no more fragile than gradle is generally and our old build scripts are just as kludgy (e.g. Studio always flagging the root one red despite it working - now no longer the case).
• Equalizes the coroutines versions for desktop and android. Same for purity plugin and annotations.
• Upgrades mockito
• Tested with debug desktop, desktop:dist, debug android run config, assembleDebug. Local assembleRelease still fails same as master - see last F-droid issue.
• Studio's automatic yellow-squiggly "hey there's a newer version of that" now works from the toml file for all of them.

[yairm210]

Oh geez :|
Every time there's another gradle update there's another level of abstraction
Now we need to guess that "lib.coroutines.core" exists? Or does IDEA automagically know?

[SomeTroglodyte]

need to guess

No. The names under libs are under our control and can be whatever we want. I could map org.troglodytes.anonymous:breath.test:0.99.1 to libs.yairs.favourite.dependency - but the glue is hidden generated code, reminiscent of .net a bit... So from that angle you're right. IDEA automagically knows to glue the gradle/libs.versions.toml file to an libs identifier in most build scripts (the one in buildSrc needs to glue it manually - and wouldn't need to if it weren't for that misnamed image packer).

Point is, all which is externally mandated is in one place, organized in sections. One has the version numbers one bumps from time to time, the other the module / artifact names. Actual build scripts only deal with monikers we define and would typically never even access a version (though they can).

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved.