Glyphs subsetting powered by wasm-based harfbuzzjs and woff2 encoder & decoder.

Follow-up of #8345 due to the mentioned limitations, mainly the inability to handle kerning (GPOS) and ligatures (GSUB) subsetting, resulting in layout shifts. Instead, relying on Harfbuzz seems as the only viable solution (used in browser and server-side) that performs subsetting also on these tables.

Business value
Decreases size of each inlined font by up to 95% (dependening on the used characters).

Closes #8300

TODO

• Handle comments in feat: subset font glyphs for SVG export #8345
• Test server-side use cases
• Test utils standalone, as currently it ignores all external packages in its prod build
• Test lazy loading of fonts & wasm works correctly
• Test subsetting works correctly on different font faces, with advanced kerning & ligatures

Consider adding loading WASM from URL

• Likely won't increase the bandiwdth that much, as it's lazy-fetched only the first time user triggers "Export as SVG" (ignored from sw prefetch). Later it's cached in memory (so subsequent call won't try to load it again) and cached by the service worker (CacheFirst, so subsequent visits won't fetch it again). Loading all WASM from binary buffer will also keep us consistent with the server-side and other use cases and avoids issues with network restrictions. In the future we might consider another wasmloader based on WebAssembly.instantiateStreaming, which might be worth for bigger modules also due to perf. @dwelle thoughts?

Also, all the lazy loaded chunks add just about 750kB (gzipped), mainly as we use just a harfbuzz subset.

Consider adding a cache for fonts so they are not loaded for each library item (might be another PR)

• Not needed for now, instead library items don't contain @font-face definitions at all, though might change in the future with custom fonts