fix!: adapt new engine range for Mocha 11

[voxpelli]

As we prepare for the next step of Mocha its time to get rid of some of the baggage that's stopping us from updating dependencies and using modern language features.

As a dev dependency that other open source projects rely on we can't be too aggressive with this bump – eg. dropping Node 18 is sadly too soon.

To make as little hassle as possible for users it makes sense to align our version range with other common dev dependencies, and one of the newest such releases is ESLint 9, which has a version range of ^18.18.0 || ^20.9.0 || >=21.1.0

This PR also sets up release-please for pre-releases and adds installed-check (which I maintain) to validate the engine range against that of our dependencies (running npx installed-check --engine-check --verbose it shows which modules that are missing published engine ranges and which it can't check)

Fixes #5206

[github-actions]

PR Compliance Checks Passed!

[voxpelli]

Lets do some more due diligence before dropping older Node.js versions, as eg. TS uses Mocha and has a wider engine range than suggested here, see comment here: #5148 (comment)

[Uzlopak]

LGTM

[JoshuaKGoldberg]

🚀

[voxpelli]

We need to decide on if we feel we have enough data to support a decision to bump to 16 or 18

For 16 we should double check what that means in terms of bumping dependencies, if we still remain on outdated unsupported dependencies then we have kind of bumped in vain and are not much better of with 16 than 14?

If 18 means dropping far too many projects, then that will be complex as well

I tried pulling down all the engine ranges for dependents from ecosyste.ms using my list-dependents-cli, but I think I failed

And that data has been proven
More unreliable than I would have hoped as it turns out that some heavyweight projects refuse to use engine declarations, making automated calculations less representative fastify/fastify#5667

[voxpelli]

If we don’t have time or want to do more investigation to pick between 16 and 18, then I say we stick with the original proposal and update to 18. Maybe it’s too cutting edge for some, but it’s simpler for us and we have no data to show that it would cause a lot of problems for the community.

[JoshuaKGoldberg]

👍 I don't have the energy to push back on this and don't feel strongly beyond "we should do this next week". So if nobody has the energy to investigate, and you're ok with 18, then sure - 18 it is.

[JoshuaKGoldberg]

🚀

[JoshuaKGoldberg]

[Docs] Just noting, we'll also want to do a find-all for any reference to Node.js 14. For example, .github/DEVELOPMENT.md.

[voxpelli]

In this or in a follow up PR?

Feel free to merge this one when you feel it’s ready