Add GradlePlugin trait

[shanman190]

What's changed?

Added a trait implementing to find direct and transitive Gradle plugins and relevant information about them.

What's your motivation?

More traits? 😆

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

Nothing in particular

Anyone you would like to review specifically?

Anybody.

Have you considered any alternatives or workarounds?

N/A

Any additional context

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[shanman190]

It would be most ideal that the FieldAccess and Identifier cases were able to specify the full class name via type attribution. Unfortunately, the types weren't available even after adding the OpenRewrite plugin to the classpath.

I didn't feel comfortable either with forcing the class name in from either value due to the possibility of all other kinds of code combinations that could arise from real world usage.

TODOs:

• Add alias support from Gradle Version Catalogs. Like FieldAccess and Identifier, this probably won't carry much useful information at first due to the lack thereof in the model and markers.
• Add test case for settings.gradle(.kts)

[Jenson3210]

I think this is awesome!
If possible, we could enhance it with the versions if the version itself is declared higher up / somewhere else in the cursor.
But if not possible in an accurate way, we can also leave it.

[knutwannheden]

Wondering if we should have a gradleVersionCatalog() or similar.

[shanman190]

Definitely a good candidate for a potential helper method. The default file name that is picked up automatically by Gradle is gradle/libs.versions.toml, so we'd probably align in some capacity to that if we chose to adopt such a helper.