As an Acorn UI app developer, I'd like to be able to easily use the recommended/default versions of AUI related dependencies.

[fuzzyweapon]

If a acornui dependency changes for a particular version of Acorn UI, app projects must all update their dependency versions.

• [x] A. evolve the use of Gradle properties in plugin(s) to use centralized defaults
• [ ] B. evaluate two approaches for plugin - BOM platform support vs manually providing version alignment through resolve rules or dependency constraints
• [ ] C. publish a BOM so that these dependencies can be treated as a platform - spike using java platform plugin with kotlin MPP

A. should retain allowing users to override defaults via property, ideally should support override via DSL plugin extension configuration, and provide a common way of accessing these defaults from plugin source.

C. The BOM is a way to expose those easily to the user in a way that they can use Gradle to enforce those versions by treating the dependencies as a 'platform'. This really helps out users when they need to add new first-level dependencies on lwjgl, etc that are exposed by the api but not declared (for whatever reason) as api dependencies back in the acornui gradle project. Users don't need to know the individual property name we use by convention simply to use default properties. Gradle provides increased support.

B. If the plugin(s) use a BOM to enforce its own dependencies, it might be possible to de-couple version bumps of acornui dependencies used there-in from plugins. AKA, we wouldn't have to publish new plugin versions simply because dependency version bumps and users wouldn't be dependent on us to release a new plugin every time we release a new acornui version. In the future, CI could 'certify' officially published BOMs work with the plugin by running integration tests. In the far future, this could extend to CI generating something like an approved BOM file that can be used in conjunction with the plugin so the plugin can restrict or warn users, dynamically select the best verified BOM, etc. Or other similar offshoot ideas, depending on needs.

[fuzzyweapon]

A provided by #24 Could handle things like getJvmMain better where there is validation and dynamic fallbacks for user input data. Some problems that were run into were:

• lazily calling the method for the map value (i.e. getJvmMain() was firing when the map was instantiated, meaning that it was doing validation in the root plugin where jvm main isn't needed, and where it will cause errors in validation resolution that are hard to determine the root cause)
• allowing for validation on user input