It looks like we have several WPT tests failing due to lack of support for
transform-box: content-box
transform-box: stroke-box

Specifically:
https://wpt.fyi/results/css/css-transforms/parsing/transform-box-computed.html
https://wpt.fyi/results/css/css-transforms/parsing/transform-box-valid.html

(Safari/WebKit seems to support them. Chrome/Blink does not yet; that's tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=924472 )

spec link: https://drafts.csswg.org/css-transforms-1/#transform-box

It looks like these keywords were added in response to
https://github.com/w3c/csswg-drafts/issues/999#issuecomment-391431901
(csswg resolution in https://github.com/w3c/csswg-drafts/issues/999#issuecomment-398823684 )

Per spec, the initial value of transform-box should be view-box.
https://drafts.csswg.org/css-transforms-1/#transform-box

This doesn't have impact on the mapping of transform-box for SVG and CSS
layout. Just make sure the initial value is correct.

Also, add a prefernce for content-box and stroke-box. So we have to
define a new type, TransformBox, and let content-box and stroke-box
behind the preference.

Refactor this structure to match spec and make us easier to support
content-box and stroke-box.

Basically, the transform-box mapping is:

1. For SVG elements without associated CSS layout box, the used value for
   content-box is fill-box and for border-box is stroke-box.
2. For elements with associated CSS layout box, the used value for fill-box
   is content-box and for stroke-box and view-box is border-box.

So we use the switch-case for each layout, to map the box correctly.

Use a valid content-box for CSS layout. For SVG layout, just map it to
fill-box.

In order to pass the wpt, we have to use Moz2D to get the stroke
bounding box for stroke-box, because we cannot get the simple bounds for
irregular shape elements, e.g. path elements.

It's necessary to use a tigher stroke bounding box to get the proper
coordinate of the transform origin. However, GetStrokedBounds() might not
tight enough for some irregular shapes. In any case, it is still better
than using PathExtentsToMaxStrokeExtents(), which is the worst case
because it uses the maximum possible stroke extents (and this is how we
calculate the svg frame rect for invaliation). Obviously it's not suitable
for computing the proper transform-box, so we add an extra flag to enable
the way to get stroke bounds with Moz2D APIs, and this is called only
for transform-box now.

https://hg.mozilla.org/mozilla-central/rev/9c22e16e0567
https://hg.mozilla.org/mozilla-central/rev/473ebe5ec7aa
https://hg.mozilla.org/mozilla-central/rev/d9b057905efd
https://hg.mozilla.org/mozilla-central/rev/803ea4d17810
https://hg.mozilla.org/mozilla-central/rev/e215151d2549