Add configurations which include N.0.0 releases

[dominykas]

Original point raised in #6 (comment) (and subsequent discussion in the PR)

Strictly speaking, even though the general recommendation is to always run the latest version of Node.js in production, and even though older versions in any Node.js major release are considered unsupported, the declaration of "engines": ">= N" in package.json implies that the package should work in N.0.0.

This means that people should test in N.0.0 to avoid accidentally breaking downstream users by using features available only in the latest releases and we could possibly try to find a way to provide such a configuration.

Some discussion points:

• Should we evangelize this to be the default in the ecosystem (and move on to include N.0.0 in future gte-N.yml files)?
• Should we do it at all? Some package maintainers are likely to just bump major (as they should) when they introduce breaking changes (new minimum Node.js version requirement) and move on. This means that they should likely manually update their build matrix to include the minimum supported version explicitly - it is infeasible to provide all possible minimum version configurations.
• Does the "all minors" config (Add configurations which include all minor releases #10) solve the issue well enough to not bother with a separate config?
• Similar decision needed in Add configurations which include all minor releases #10 - should we use a subfolder or a file suffix for this configuration?
• Naming (be it a new strategy, or a folder, or a suffix)
• Do we need to include the N.0.0 for each major release line in the matrix? Can we get away with just one extra build job with the very earliest N.0.0 (which by definition will break if you try to use features from (N+1).0.0)?
• Does semver need a way to define a range which asks for a latest (known) version, rather than all versions greater than N? See also: Communicating that only the latest version of a major release line is supported package-maintenance#393

[ljharb]

I've certainly done this manually on a couple packages, but I've not found it to be necessary on hundreds of others.

(I think we would need to have an N.0.0 for every N, not just one overall)