report: use narrow formatting for opportunity units

[brendankenny]

fixes #14337

Everyone (including at least a few standards bodies) seem to agree the narrow s is way better than the short sec. We seemed in agreement that sec is weird as well, so making the switch.

That also allows us to narrow the text area again. It doesn't really make much sense to be specifying in terms of font-size, so I switched us over to using 7ch, which for Roboto is roughly equivalent to the 4x we were using before #14619. ch isn't perfect if it's not a monospaced type, but it's a much more logical relative unit for a width.

We could maybe go narrower, but unfortunately some locales still use a space before the unit and a period after for narrow formatting, so this lets us get xx.xxs for most locales and x.xx s. everywhere without wrapping (Tamil appears to result in the longest opportunity time strings).

We could bump it up to 7.5ch? Or just live with the . wrapping to the next line in that case until opportunity rendering is refactored (notably just sample_v2's first 3.30 wraps in Tamil on main with the current calc(5 * var(--report-font-size)) since it's rendered as 3.30 விநாடி).

Before:

After:

Tamil:

[connorjclark]

s SGTM

I'd prefer to keep the additional space. I confirmed that 7.5ch is enough to render xx.xx in Tamil without wrapping.

[alexnj]

There should be a space between time numeric value and unit.

[brendankenny]

There should be a space between time numeric value and unit.

The space/no-space comes from Intl.FormatNumber, which is from the CLDR and a decision well upstream.

Space is my preference too, but I would also prefer treating s as an SI symbol and not something to be localized, but until we make a solid case for that, deferring to Intl seems like our best option.

[alexnj]

TIL. https://github.com/unicode-cldr/cldr-units-full/blob/master/main/en/units.json#L2235