doc: ensure that GPG key used to sign the latest LTS release (12.6.1), as well as 13.12.0, & 8.16.0

[haqer1]

… is mentioned in README(.md) (alternative approach (just in case decision-makers want to keep C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 key listed higher (as current) & 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946 lower (as older)))

Update README.md.

Fixes: #32559

Checklist

• documentation is changed or added
• commit message follows commit guidelines

[MylesBorins]

PTAL at #32560 (comment) as to why I don't think this should land

[haqer1]

Just in case, i'm also listing the error the user gets at present in French:

$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Signature faite le ...
gpg:                avec la clef RSA 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Impossible de vérifier la signature : Pas de clef publique

IMHO, because
0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
is not listed in
https://github.com/nodejs/node/blob/master/README.md
either this PR or #32560 should land.

P.S. IMHO, users shouldn't be required to spend extra time on this (for whatever reason this has happened), while there is a section in README(.md) which is specifically made to facilitate signature verification. So at present (assumingly) all the keys for (assumingly) all the releases are listed there, except this 1 key for this 1 LTS release. Which is why i've spent some time to ask for it to be corrected.

[haqer1]

The same stuff as in #32560 (comment), but preserving spaces (& in French):

.../nodejs/8.16.0$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Signature faite le <date/>
gpg:                avec la clef RSA 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Impossible de vérifier la signature : Pas de clef publique
.../nodejs/13.12.0$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Signature faite le <date/>
gpg:                avec la clef RSA 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946
gpg: Impossible de vérifier la signature : Pas de clef publique

The fact that users see 0EFFE1BCEFD9C84E3D098152933B01F40B5CA946 for (at least) 3 releases, IMHO, is an argument in favor of landing #32560 (as opposed to this PR).

[MylesBorins]

Landed #32591 instead