Add declarative Gradle upgrade recipes

[timtebeek]

What's your motivation?

When upgrading Java versions folks also need to upgrade older Gradle versions. While upgrading the wrapper is one part of that upgrade, at times there's required changes as well, in particular going from 4.x to 5.0. Some of these changes we can already automate, others might still follow now that the framework for these migrations is there.

Anything in particular you'd like reviewers to focus on?

• For the RemoveEnableFeaturePreview record I went by when those keys were dropped from the enum, going by latest.patch; seemed ok, but could be double checked as documentation was hard to find.
• Intentionally left out compile -> api/implementation, although that'll be a bigger pain point. Anything we can do for reasonable coverage here? Perhaps look if java-library plugin is defined and base our behavior on that? Or at worst merely post a comment on the first case?

Have you considered any alternatives or workarounds?

The components here were already available. We could document the steps and considerations for compile -> api/implementation, and how they could be achieved with recipes.

Any additional context

• Gradle wrapper upgrade recipe to 7.x+ is not updating "compile" dependencies to "implementation" in build.gradle files #4194

[shanman190]

General question, but are these more migration recipes and as such should follow the migration ADR?

[timtebeek]

Good call! Wasn't aware of that doc, but helps to standardize where possible.

Any other steps that come to mind? Things like required common plugin upgrades, or removal of jcenter?

Of course we can expand the steps later as well; just let me know when you'd consider this ready for a first merge.

[shanman190]

So the jcenter() method is still available as of Gradle 8.10.1, but with that said JFrog has redirected https://jcenter.bintray.com/ to https://repo1.maven.org/maven2/. So in practice it's now the same as mavenCentral(). So I could go either way there.