Standardize layout constraints for operator stretching

[fred-wang]

cc @bfgeek

I'm opening this for the record. This is described in https://mathml-refresh.github.io/mathml-core/#dfn-inline-stretch-size-constraint and used elsewhere in the MathML core specification.

Ideally, we should define them in the CSS layout API as three new double values:
https://drafts.css-houdini.org/css-layout-api/#layout-constraints

That way, if people write their own custom MathML layout (e.g. a custom mo operator relying on variable fonts or an mrow-like custom layout stretching its children) they could still receive / pass the layout constraints from their parent / to their childen.

As I said for other CSS features, this is still very hypothetical since math polyfills don't use modern techniques yet. So it makes sense to postpone this for now.

[fred-wang]

They should probably have "Target" in their names to clarify that this is a target size, operators generally stretch to the smallest available size above that target and may even fail to stretch at all ; this depends on what is provided by the font.

[fred-wang]

I'm removing this "MathML 4" label. Although this is something interesting to rely on in order to implement for MathML full, the actual low-level details would be in MathML Core or houdini specs instead.