Add support for Blurhash in FastBoot

[simonihmig]

Blurhash requires a JS library to decode, no browser understands it natively. This however provides the challenge that SSR (FastBoot) does not show the LQIP until the app is fully hydrated, when the decoding happens as part of the app - as it was implemented before. But for any FastBoot/prember rendered app this is useless, at least for the initial render, as the loading of the actual image has already started - concurrently with also loading the JS - before the placeholder can be shown. When testing this out in a real app (ember-website, see ember-learn/ember-website#769) you could see that a bunch of images have already been fully loaded (thanks to proper sizes and AVIF, yeah!) before the app.js kicked in.

This is now a major refactoring, with a different approach. When Blurhash is used (and only then!), a separate blurhash.js script is created (using broccoli-rollup) that is injected into index.html before the actual app's JS. It will decode the blurhashes and apply the decoded image onto all images that have been explicitly tagged (with data-eri-bh attribute) in the static HTML rendered by FastBoot. So that happens eagerly before the app is loaded, with just the minimal amount of JS.

This script also exposes the blurhash to data-URL function (as a global), so we can reuse this from our SPA for run-time decoding (e.g. new images rendered in a different route after the app has hydrated), without duplicating this in our app's code.

This and the previous effort (see #162) of rendering LQIP through static CSS (generated by the addon) rather than dynamically applying styles (through modifiers) should provide full FastBoot support for our LQIP-techniques. Closes #161.

cc @lolmaus @andreasschacht @lifeart 👆

[lifeart]

as addition, we could "decode" blurhashes in templates, as AST plugin, it will increase bundle size, but it should save more CPU in fastboot mode.