Drop uuid dependency to simplify wasm use

[rsheeter]

uuid pulls in getrandom and thus bumps fontc directly into https://docs.rs/getrandom/#webassembly-support.

d50b59c approaches this by pulling in more features, this PR proposes to simply drop the uuid dependency. This is consistent with https://unifiedfontobject.org/versions/ufo3/conventions/#identifiers: there is no general identifier algorithm, only the consumer of norad knows what they want.

If we really really want auto-uuid identifiers I suggest we make that an opt-in feature.

If I point to the updated norad locally cargo build -p ufo2fontir --target wasm32-unknown-unknown now passes, which in turn means the fontc build does too, as requested in googlefonts/fontc#1215.

Add the usual wasm check to rust.yml.

Bump the patch version of norad to reflect the break in compatibility.

[cmyr]

So looking through this PR and then doing some archaeology, it looks like we do need some way to generate identifiers, due to how lib data is serialized.

Basically: certain objects (like glyphs) have a convention where there the lib can contain a key public.objectLibs which contains additional lib data that is associated with a particular contour, point, component etc., and this data is keyed based on the identifier of that object.

In norad, we store this lib data inside the appropriate object, reading and writing it to public.objectLib at the serialization boundary; this is a much nicer API, since you just set the lib data on the object directly, instead of needing to do a big dance where you get/set an identifier for the object and then go manaully update the lib in the parent.

A consequence of this, however, is that we do need to be able to generate unique identifiers, or else we can't correctly serialize/deserialize these objects.

While we don't need to use the uuid crate to generate these identifiers, we likely do need some sort of entropy, which will necessarily run into the same problems (we'll need to specify some feature on wasm.)

Do we have a reason to believe that the current setup doesn't work, or have we just not released a new version yet?

[rsheeter]

I only need to read so I'd rather prune the unwanted dependency than make it work. Per IM, making it opt-out also works, not tied to the exact approach in this PR.

[rsheeter]

Closing, @cmyr will add an opt-out