Recalibrate the `opsz` axis

Sadly I need to ask to 'recalibrate' the `opsz` axis.

### Summary/Conclusion

The way opsz values are interpreted has become ambiguous, by 1⅓. 72 or 96 is a big difference. It is important for everyone to come into consensus on what opsz units mean as soon as possible, and the next round of GF VF fonts can demonstrate leadership here.

### Details

#### 1. ‘CSS pt’ is not ‘physical pt’ – and ‘CSS px’ has no consistent physical size

The OT spec says opsz values are meant to be physical Points, but "css pt" is not actually physical pt, it is "4/3 * px" - and px is not defined as a physical unit. This by itself is not too big of an issue, but is not ideal :)

#### 2. Zero browsers follow the OT spec for opsz == pt, all use px instead

They all have decided to use px instead of pt, thus "mis-implementing" auto-opsz. This is a big deal.

Eg, Google Sans Text is currently coded to start interpolating at 18 pt and be fully used at 14 pt, but currently GST will start at 24 pt and be fully used at 18.6 pt – a big difference!

#### 3. CSS says pt == 4/3 px, but Apple says pt == px

How did (2) happen? Because all Apple systems have always broken the CSS spec and treated pt == px, and because Apple was the first to implement auto opsz, all others ended up matching them by using px instead of pt.

4. A solution (1) and (3) is CSS authors scaling opsz values

The proposal to W3C CSS WG ([github.com/w3c/csswg-drafts/issues/4430](https://github.com/w3c/csswg-drafts/issues/4430)) by Laurence Penney and Adam Twardoch is (and insanely long discussion and is) for CSS authors to adjust the way opsz unit are interpreted by some factor, so that if you want to scale opsz for apple systems to match all others, you can – and also if you want to deal with (1) – by end-users calibrating their devices so you can scale css pt to == physical pt, you can.

#### 5. A solution to (2) is to update the OT spec

John Hudson was co-author of Microsoft's opsz definition, and his proposal is to update the OT spec `opsz` definition from physical pt of 1/72nd of an actual inch to 1/96th, which is as close as we can get to 'css px' values (and for mobile apps, dp in Android, and pt and px in macOS/iOS).

Since no design/desktop app has shipped auto-opsz yet, I think we are still within a window of opportunity to make this change without major disruption; such non-px based apps can get a pt value by a simple 4/3x multiplication.

#### 6. Anticipating this, all Google Fonts fonts with `opsz` axes need to calibrate the axis on 1/96in not 1/72in

Here we are :)

So, I'm asking you to change the values of the masters appropriately, and rename pt to px in named instance strings.

(Related to https://github.com/TypeNetwork/Amstelvar/issues/175)