Avoid underestimation of min/max stretchy horizontal operators

cc @bfgeek

As you can see on the screenshot, with how math fonts are designed:

• The width of a vertical stretchy operator (e.g. a left parenthesis) is not constant.
• It is not always possible to perfectly stretch to a given target size. In particular for horizontal stretching, the operator (e.g. horizontal over brace) might end up a bit larger than its siblings.

One can use scale transform to distort the glyph, but that would go against the will of the font designer and might give poor math rendering.

This has implications in min/max size computation (https://mathml-refresh.github.io/mathml-core/#layout-of-operators):

• We cannot determine the preferred width of a vertical stretchy operator since vertical metrics are unknown during min/max size computation. MathML Core addresses that by taking the maximum of all widths. This may be an overestimation of the final width.

• We cannot even determine the preferred width of a horizontal stretchy operators since we cannot use layout constraint during min/max size computation. MathML Core addresses that by taking the width of the unstretched operator. This may be an underestimation of the final width.

and has consequences for the rest of the page layout:

• When the min/max size is overestimated, linebreaking might not be optimal. For example, an inline MathML formula in a paragraph of text can be moved to the next line even if there is enough room for it on the current line. Or a table cell containing a MathML formula might be larger than what is needed to contain the formula.

• When the min/max size is underestimated, the situation is the opposite: the inline formula in a paragraph may overflow instead of forcing a line break and moving to the next line ; a MathML formula inside a table may overflow its containing cell.

I think overestimation is an acceptable approximation, at worst it adds some extra white space. Underestimation can cause more annoying overflow bugs, so should be preferably avoided. Hence I'd like to propose the following change:
( https://mathml-refresh.github.io/mathml-core/#underscripts-and-overscripts-munder-mover-munderover )

• When calculating the inline size of munder/mover/munderover, the unstretched size of horizontal stretchy embellished operators is used.

(Note that these operators remain laid out with the stretched size and the horizontal position remains as defined in the spec)

This means that the width matches the min/max calculation and we get rid of the approximation error. Or said otherwise, we just have some possible overflow on each side of each munderover rather than an error accumulated for the min/max size of the math root.

Note that with MathML Core, one may already have to layout stretchy horizontal operators twice (when all children are of this kind) and per discussion in w3c/mathml#124, Neil thinks it is important to keep this anyway. (I would still prefer to avoid this second layout for vertical operators and keep the current description in MathML Core)

Start with the MathML Core sections on layout of operators and underscripts/overscripts (munder/mover/munderover), plus the linked w3c/mathml#124 discussion. Done means reaching agreement on the proposed min/max sizing behavior and updating the specification text; the payload names no implementation files or tests.