Add tool to generate event UIDs and update README

[traviscross]

According to the iCalendar (IETF) RFC 5545, the UID for each event must be "globally unique". In this context, that means that the identifier must not collide with any other identifier for any other calendar event across all calendars, ever.

The way we were suggesting that people generate these, by calling out to date, unfortunately falls a bit short of being able to assure this.

Let's instead add a small tool to generate sufficiently-long randomly-generated identifiers to make it easy for people to do the right thing here for new events.

Merge this one after:

• Handle calendar repo containing xtask in CI calendar-generation#15
• License under MIT OR Apache-2.0 #66

cc @davidtwco

[apiraino]

Why not just suggest using uuidgen or any similar tool to generate UID (or UUID to be more precise)? We could spare dependencies and complexity to this tool :)

[traviscross]

Well, that's the idea here, is to spare dependencies so we don't need to ask people to install anything else. This also means that we produce these UIDs in the consistent and exactly desired way.

This too isn't particularly complicated, and only depends on getrandom.

Most of the small number of lines of code here is just settings things up for the xtask pattern, and I can imagine other useful xtask helpers we might want. E.g., it'd be nice to have one that prompts the user for details and generates the TOML for an event.

[apiraino]

I can't speak for many operating systems, but in Debian a UUID generator is marked as "required", in Fedora too (afaik). I think we can safely assume that it is installed by default everywhere? What's the dependency chain of xtask instead?

Anyway, just my .2 cents to avoid bloat.

[traviscross]

What's the dependency chain of xtask instead?

Rust and the getrandom crate (handled automatically by cargo), that's it.

[davidtwco]

Can you add a check/fmt/test for this utility in the CI?