The @font-face unicode-range feature is not supported for local fonts

[andreubotella]

Describe the bug:
#32164 added support for various @font-face features, including unicode-range. However, if the source for the given @font-face block that ends up being chosen is a local font, unicode-range will be ignored. This seems to be because all local fonts are loaded when the process starts, and their FontTemplateDescription doesn't change, even when they're used as part of a @font-face block.

I noticed this while testing #32171, since the css/css-values/ch-unit-018.html WPT test relies on unicode-range with the Ahem font (which can be loaded locally, and is in my system) to test that the advance width of the ch unit is not loaded from the first available font if that doesn't include the '0' character.

To Reproduce:

<style>
@font-face {
  font-family: AhemA;
  src: local(Ahem);  /* This assumes you have Ahem installed. */
  unicode-range: U+0041;
}
div {
  font-family: AhemA, serif;
}
</style>
<div>sdfdsAfsdf</div>

[mrobinson]

This will likely have to wait until @font-face are stored in the per-layout data structures: #32033.

[andreubotella]

This will likely have to wait until @font-face are stored in the per-layout data structures: #32033.

Maybe unicode-range can be stored in the per-layout structure, but about other @font-face features like font-style and font-weight? If those properties are specified in a @font-face rule, they take precedence over the properties in the underlying font data as far as font matching is concerned, which (if I understand the existing font design and the proposed redesign correctly) would mean the font cache thread would need to have access to them.

[mrobinson]

The FontContext will hold all per-layout FontTemplates which will allow specifying unicode-range, font-style, etc. These special templates will be per-layout even if they ultimately point to system fonts.

[mrobinson]

This should have been fixed by #32303.