Use more precise supported Node.js version ranges

Package(s)

@webmangler/benchmarking (v0.1.1), @webmangler/language-css (v0.1.31), @webmangler/language-html (v0.1.27), @webmangler/language-js (v0.1.29), @webmangler/language-utils (v0.1.28), @webmangler/mangler-css-classes (v0.1.24), @webmangler/mangler-css-variables (v0.1.24), @webmangler/mangler-html-attributes (v0.1.24), @webmangler/mangler-html-ids (v0.1.23), @webmangler/mangler-utils (v0.1.29), @webmangler/testing (v0.1.7), @webmangler/types (v0.1.27)

Description

Most packages (except @webmangler/core (v0.1.28) and @webmangler/cli (v0.1.11)) currently specify the open-ended version range >=12.16.0 as supported Node.js engines, example:

webmangler/packages/language-css/package.json

Lines 34 to 36 in 8e32df2

    
           "engines": { 
        
             "node": ">=12.16.0" 
        
           }

This should be changed to be more precise so that the supported Node.js engines are accurate and can reasonably be supported.

Progress

Motivation

Using an open version range (like >=12.16.0) implicitly means any future Node.js version is supported, including non-LTS releases of Node.js. Supporting non-LTS release is not necessarily desirable, and supporting all future versions of Node.js is not really possible.

Proposal

Like the core and cli, adopt a supported version range that is a conjunction of LTS releases, optionally with support for non-LTS releases on request.

When a new LTS release of Node.js is available, support will have to be added manually and a release created in order to officially provide support for the new Node.js version.

Alternatives

Keep using open-ended version ranges.

Not desirable per the main description.
Use open-ended version ranges for the latest LTS, in (optional) conjunction with older releases.

While not entirely unreasonable, I personally don't see much value in providing immediate support for a new LTS release at the risk of not actually being compatible with that new version.

Notes

Relates to #440
As this concerns many packages, individual package labels won't be applied to this issue.