Build an asset font for custom icons

[gnprice]

Much like we do in zulip-mobile and Zulip web. We'll want a font file containing the icons, and then a generated Dart file that maps icon names to glyph IDs in the font.

For references, see:

• tools/build-icon-font in zulip-mobile, which is a Node script doing a similar job using the NPM package @vusion/webfonts-generator
• the Dart script that Lucide uses to generate the mapping file when building their Flutter package (but that script consumes a file that something else generated, which provides the data just in a different format)

It would be nice if we can write the script purely in Dart. If we can't readily lay hands on appropriate tools to make that easy, we could settle for having a Node script so that we can use NPM packages.

The generated output — both the font file and the generated Dart file — should be committed to the repo, just like we do for other generated files and just like we do for the corresponding files in zulip-mobile. That way the script only has to be run when changing the set of icons, and there's no complication added to a normal development cycle.

[gnprice]

The custom icons we'll want are those in @zulip/shared, used by Zulip web and zulip-mobile.

Potentially we might also want to include other icons not found there.

One known place where we'll want to use a custom icon is in #119, in the spot that replaces an avatar for group DM threads; see chat thread. If we write this script after #119 is already done, then we'll have some other icon there initially and we'll want to replace it with the custom icon.

[gnprice]

If we can't readily lay hands on appropriate tools to make that easy, we could settle for having a Node script so that we can use NPM packages.

In #219 I went for the latter. I looked in a couple of directions for leads on alternative tools to use, but didn't find anything helpful:

• Looking into how Lucide's data is generated, it's another web of NPM packages. So that's no more appealing than using the ones we already know about.
• Looking into Flutter's own Material icon set, the font file and the icon-to-codepoint mapping are downloaded as static assets in much the same way as the Flutter SDK is. The script that regenerates the Icons data consumes that downloaded icon-to-codepoint mapping. So that leaves it opaque how those downloaded files are generated.
  • It might be possible to pursue this trail further, but I didn't because at that point the files appear to be generic to Material Design and not specific to Flutter, which means they're likely to again come from a non-Dart toolchain.

So with #219 we'll have one subdirectory with a tiny package.json, which downloads 38MB of transitive dependencies. 🤷 It'll be fine. None of it needs to run in a normal development cycle; only when editing the set of icons that exist, and in CI (once we add CI: #60).