Remove limitation on the frequency of semver-minor LTS relesease

I'd like to propose we remove the unofficial rule we have limiting the frequency of semver-minor LTS releases to one per quarter (I think?). Having prepared some of those releases, I think the rule is counterproductive, error-prone, and puts a huge burden on the releasers. Here are a few reasons I would like to remove the rule and let the releaser decide each time whether they are going to prepare a minor or a patch release:

• The main branch is not managed in a way that facilitates our work. Once a few semver-minor changes have landed, a lot of subsequent semver-patch changes will depend on them, making it difficult to find commits that can land cleanly on the LTS branch. The consequence of this is that we tend to have relatively small patch releases followed by a huge minor release like v16.17.0 today.
• Because most of the semver-patch commits cannot land cleanly without their semver-minor dependencies, the release preparation takes a very long time as the releaser has to check for each conflicting commit why it doesn't apply. Then they either add the appropriate label (dont-land, backport-blocked, backport-requested) or fix the conflict manually. Each manual fix takes time and may introduce bugs even if it seems trivial.
• Users have to wait many months for changes they care about (many of these changes being semver-patch bug fixes) to land on LTS.

@nodejs/lts

Start by reviewing the LTS release workflow and the discussion in this issue, focusing on how semver-patch and semver-minor changes move from main to the LTS branch. Examine the dont-land, backport-blocked, and backport-requested labels. Done means the release-frequency rule has a documented decision and the release guidance reflects it.