run minifiers on ecmarkup outputs and assets

[michaelficarra]

Fixes #222.

File	Normal gzip	Minified gzip	Savings
assets/css/ecmarkup.css	6698	5681	15.2%
assets/css/print.css	3135	2503	20.2%
assets/img/ecma-header.svg	3087	3026	2.0%
assets/img/print-front-cover.svg	141443	141324	0.0%
assets/img/print-inside-cover.svg	4313	3293	23.6%
assets/js/ecmarkup.js	267778	262555	2.0%
out.html	878913	828946	5.7%

Disclaimer: I used AI in the process of making this PR.

[bakkot]

How'd you pick the minifiers? (or did you just let the AI pick?) e.g. per this page lightningcss does a substantially better job.

[michaelficarra]

I picked html-minifier-terser. The AI picked the others. I can swap in lightningcss and see how it does.

[michaelficarra]

Unfortunately there's an issue with lightningcss's handling of our non-standard Prince directives in print.css. From https://lightningcss.dev/docs.html,

By default, Lightning CSS is strict, and will error when parsing an invalid rule or declaration. However, sometimes you may encounter a third party library that you can't easily modify, which unintentionally contains invalid syntax, or IE-specific hacks. In these cases, you can enable the errorRecovery option (or --error-recovery CLI flag). This will skip over invalid rules and declarations, omitting them in the output, and producing a warning instead of an error. You should also open an issue or PR to fix the issue in the library if possible.

Notice that it removes them, it doesn't just pass them through unchanged.

Additionally, we can swap out terser for swc, which some people consider better, but I don't really like using html-minifier-terser (which will handle inline JS using terser) but then using swc for external JS. The difference was only 25 bytes on ecmarkup.js. So I don't think we should change any of the chosen minifiers.

[bakkot]

wfm other than comment