Standardize layout constraints for operator stretching

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.

Start with the MathML Core definition of the inline stretch size constraint and the CSS Houdini Layout API layout-constraints section linked in the issue. Determine whether the proposed three double values are still appropriate and how custom MathML layouts would pass them between parents and children. Done would require an agreed CSS Layout API design, not just a local repository change.