#350 - Rework publishing plugins so they can be used externally and on multi-project builds

[jdaugherty]

This change resolves #350. At a high level it:

1. Removes unused extension properties
2. Removes "internal" from publish namespaces & Rename plugins to reflect they aren't only for grails central
3. Updates the gradle enterprise logic that was commented out with the initial upgrade to grails 7 (jumps to latest version)
4. Updates the github actions to match grails-core (to pickup the gradle enterprise updates)
5. Adds documentation for the publish plugin
6. Supports publishing to artifactory or maven central for snapshots
7. Migrates the username, password, and url properties to properties / environment variables only. using a publish plugin will require a snapshot url property to be defined based on the snapshot repository type. My assumption is we'll add these to the gradle.properties in each project
8. Supports defining the grailsPublish block at the subproject level.

With these changes, any project can remove the gradle boiler plate of publishing to maven central & an artifactory snapshot instance. Technically, it doesn't have to be a grails project to use this plugin. If it is a grails plugin then the plugin.xml will be added as an artifact for the publish plugin and for the profile plugin it will generate the associated profile.xml.

I tested the snapshot portion of this logic with this code spring security rest code. @jeffscottbrown was kind enough to assist in testing. You can find an example artifact here - (I published to the wrong repo initially, oops).

Once this change is merged, all of the repositories with grailsPublish will have broken publishing since the urls will be missing. I plan to go through all of them quickly and set the appropriate snapshot url (plugins go here & profiles go here) to fix this breakage. Separately, I'll go through the various multi-projects that couldn't use grailsPublish and switch them to grails publish (like the spring security rest plugin).

As part of the milestone announcement, we can offer these plugins to people so they can use them to simplify plugin upgrades. I'd like to provide an example github action too.

[matrei]

Nice work James! This should hopefully make it easier to publish in the future.

It is hard to test these kind of changes.
Also, I think some projects may depend on it so it will be exciting to see if it is backwards compatible. We'll see 😄.
(I see now that you already mentioned this in your PR description 👍)

[jdaugherty]

@matrei I believe I've made all of the changes you requested.

In terms of backwards compatibility, this will intentionally break the other projects initially - I moved the hardcoded grails repo URL out of the plugin so that it can be used externally. If we define that URL at the organization level, I believe it may "just work", but when I merge this I assumed I'll go through each repo rapidly fixing or converting each repo to a simplified publish. Thank you so much for your feedback!

[matrei]

I checked what it does, and it looks like VERSION is only needed in release.yml. So it's OK to remove it here in gradle.yml.

[matrei]

You could also change the year in the license headers of changes files.

Let's try this baby out!