Document default OS policy and set default variant per node version

[tvainika]

The default operating system release used by node images has not been properly documented, and the policy of updating the operating system release underlying a specific node release has been causing unexpected behavior when the operating system release had been updated. The clearest description of the issue was in #1068, which was closed without properly documenting the maintenance policy.

Changes here in README.md I'm trying to write down sensible policy of the operating system release. There are arguably also other ways to define the OS release policy than that one.

The policy written and implemented causes different default operating system release to be used per nodejs version. In my opinion this makes sense, because the operating system support period and nodejs maintenance period should be in sync as much as possible.
The policy here defines default operating system release of both Debian and Alpine per nodejs version compared to earlier solution of defining the default release shared for all nodejs versions. This allows the operating system support period and nodejs maintenance period to be more in sync. The policy allows changing the underlying default operating system release when specific nodejs version enters LTS maintenance period. IMHO it would make sense to switch default Debian release used with Nodejs v14 to be Debian 10 (buster) instead of Debian 9 (stretch), which it is now, so it does not need to be changed during the Nodejs v14 LTS maintenance period. On the other hand Nodejs v10 LTS maintenance period ends at 2021-04-30, which is earlier than Debian 9 (stretch) extended support, which ends at June 30, 2022, and therefore Nodejs v10 default Debian release should not be changed, just my 0.02 cents. Nodejs v12 LTS maintenance ends at 2022-04-30, which is also before Debian 9 (stretch) extended support ends, which also should not be changed.

I did not analyze Alpine release timeline, but the configuration change here allows also Alpine default tag to be configured per node version.

This also cleans up some chakracore configuration support as it was removed and supporting that complex logic was in conflict of having config file per nodejs version.

[LaurentGoderre]

IMHO we don't need this extra complexity. We worked hard to get to a point were our image tagging give users the most flexibility. Users who want stability should pin to a specific OS and even specific node version while user want to get rolling LTS can do that with tags too.

[tvainika]

IMHO we don't need this extra complexity. We worked hard to get to a point were our image tagging give users the most flexibility. Users who want stability should pin to a specific OS and even specific node version while user want to get rolling LTS can do that with tags too.

If the variant specific configuration is no-go, I'd still like to see the policy documentation part here done in some form. I can write separate PR out of it if there is a common understanding of what is OS update policy. For me it sounds like there is no really a policy the base OS version gets updated.