Add a separate release process for core-recommended

From #3600889: Remove some minor constraints from core-recommended there are two parts to this:

1. We'll need to set up a release process that separately tags releases of drupal/core-recommended - this would only happen when a dependency tags a security release that is also a new minor release not covered by existing constraints.

2. We need to figure out what to do with version numbers, since we can assume that core-recommended will have every release of core + additional releases for dependency security releases.

There were two ideas for version numbering:

1. Have core-recommended increment the patch number beyond drupal/core, then when we do a core release, skip any intervening numbers so that they match.

e.g.

11.4.0 - core + core-recommended
11.4.1 - core-recommended
11.4.2 - core + core-recommended

2. Use a four digit release number:

11.4.0 - core + core-recommended

11.4.0.0 - core-recommended

11.4.1 - core + core-recommended

@godotislate pointed out that semver doesn't support four digit release numbers. Composer does for bc https://github.com/composer/composer/discussions/11456, but not officially https://getcomposer.org/doc/04-schema.md#version

However, both semver and composer support patch suffixes.

So we might be able to do:

11.4.0 - core + core-recommended

11.4.0-p1 - core-recommended

11.4.1 - core + core-recommended

As long as -p1 is recognised as > 11.4.0 (so that it gets updated to), that seems OK, and would identify it clearly as a 'bonus' core-recommended release.

You're right. It allows pre-release (1.0.0-beta1) and build metadata (1.0.0+foo) but not additional -p1.

However if composer officially supports what we want to do, I'd be happy to deviate from semver, because a lot of the problems we'd running into are that semver does not and never has resolved the problems it purports to solve.

There’s a possibility this ends in core-recommended ends up as a separate project instead of a subtree split. As long as it’s a subtree split, the same Git tags go everywhere regardless.

A release branch could be made from the last tag, commit only to core-recommended and increment version numbers, to make a release with only substantive changes in core-recommended. Same process as a security release containing only the security fixes. All other subtree splits get new tags, with no substantive changes.

Any tricks with semver features are the same as a regular patch version increment. Either there’s a subtree split and they all get all the tags, or they are independent projects that can have independent version numbers. I don’t think semver has a problem with skipping version numbers, so the rest could skip ahead to stay in sync with a core-recommended that’s gotten ahead.

Packagist.org now has immutable tags https://blog.packagist.com/an-update-on-composer-packagist-supply-chain-...

Stable version immutability on Packagist.org: Tagged versions can no longer be silently rewritten by re-tagging in git repositories.

So I believe any re-tagging would not be possible, regardless of release nodes. The subtree splits are processed and pushed on git push.