cff: Fix version number

[Finii]

The font version number stored in the CFF table can not be set individually, nor is it preserved on a read/write cycle.

Description

[why]
The version number written out to a buffer is not the number stored in font.tables.cff.topDict.version. Instead some other human readable string is used even if the cff.topDict.version has been set correctly.

The CFF version number needs to be a string representing a number and nothing else; especially it should not contain 'Version'.

Documentation [1] says this:

    version 0 SID
    This can be derived by copying the OpenType 'head' fsRevision
    field, and formatting it as a Fixed with three decimal places of
    precision.

The documentation is also valid for CFF1 in this regard.

[how]
Use the version string in the CFF table, if there is one. If not fall back to the (imho wrong) previous defaulting behavior.

[1] https://learn.microsoft.com/en-us/typography/opentype/otspec180/cff2#sectionD3

Description

Keep the version string that exists in the CFF table and do not invent one needlessly.

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

This shows reading a font file, printing the CFF font version number; then going through serialization and printing the broken CFF font version afterwards.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I did npm run test and all tests passed green (including code styling checks).
• I have added tests to cover my changes.
• My change requires a change to the documentation.
• I have updated the README accordingly.
• I have read the Contribute README section.

I would add tests to the Panose test case from #759 (to avoid merge conflicts now here).

[Finii]

I noticed more value automatisms, for example ascenders seems to be a global despite the fact that there are three different properties in fonts that describe them and they rightfully can be different and are different in a lot fonts.

Maybe these automatisms, which are handy for font-from-scratch, should be turned off on font-from-parse(). But that would be a design decision / change etc.

$ git grep -i globals\.ascender
src/tables/sfnt.mjs:    globals.ascender = font.ascender;
src/tables/sfnt.mjs:        ascender: globals.ascender,
src/tables/sfnt.mjs:        sTypoAscender: globals.ascender,
src/tables/sfnt.mjs:        sxHeight: metricsForChar(font, 'xyvw', {yMax: Math.round(globals.ascender / 2)}).yMax,
src/tables/sfnt.mjs:        fontBBox: [0, globals.yMin, globals.ascender, globals.advanceWidthMax],

I guess all the globals. can be problematic on a read-write cycle as they destroy differences in the source font that might or might not have reasons.

[Connum]

As always, please add a test for the expected values when reading/writing a font

[Finii]

As always, please add a test for the expected values when reading/writing a font

I would add tests to the Panose test case from #759 (to avoid merge conflicts now here).

Yes, no, maybe?
Maybe you did not read that? 🤔

Whatever, I can add that here (too), but the question about the location of the tests is also still unanswered, As the tests usually test code within one module, but in which module should one test a write-read cycle where several modules must coordinate. And there are no preexisting tests (that I found) that do stuff like this at all, so that is some general question you Maintainers must decide. I can then put the test(s) in an appropriate place.

Edit: typo