Replace using UUIDs with a consistent eventmaker

[sneakers-the-rat]

Fix: #139

UUIDs are hella expensive for what we need, and we are sort of inconsistent about how event ids are declared. additionally, making events is sort of cumbersome, so it would be nice to have a simple factory class to wrap up some of the repeated boilerplate there too.

the requirements for event ids are pretty simple:

• Locally unique - need to be able to tell events apart from one another, but only within a local context: someone running a bunch of runners in a given machine/cluster/etc. not worldwide global unique, nothing on the web yet.
• Ordered - would be great to be able to tell the order of events from their ID. they have timestamps, but across machines timestamps might be offset, etc.
• Cheap - we make a ton of them soooo

Just doing a simple 64-bit integer format where the first 32 bits are some random prefix, and the last 32 bits are a sequence. This gets us out of the trap of everyone just using a count() and having them all overlap (e.g. in the zmqrunner) while still being pretty cheap - we only need randomness once, at init time, and that's pretty quick, rather than every time.

I initially made a subclass of int that had properties to get the prefix and sequence numbers, but that was too slow, so i just went with a bare int with accessory construction and deconstruction methods

method	time
uuid.uuid4()	2.39 μs ± 32 ns per loop
EventID.from_prefix(12345, next(counter))	336 ns ± 4.09 ns per loop
event_id(12345, next(counter))	164 ns ± 1.86 ns per loop
event_id(12345, 5789)	149 ns ± 2.51 ns per loop
event_id(shifted, 5789, shifted=True)	94.7 ns ± 0.868 ns per loop

so ~25x faster for an operation we do literally all the time.

---

📚 Documentation preview 📚: https://noob--232.org.readthedocs.build/en/232/

[codspeed-hq]

Merging this PR will not alter performance

✅ 8 untouched benchmarks
⏩ 8 skipped benchmarks¹

---

_{Comparing snowflake-epoch-ids (032c2ab) with main (dd6e949)}

Footnotes

1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩