Allow an isolate to have a simple random uuid

[jasnell]

The jsg::Lock::getUuid() will lazily create a random uuid for the
isolate instance. It is expected that this will primarily be used for
logging/diagnostics in DO cases. The uuid is generated lazily so there
is zero cost if the uuid is never used.

( Prompted by a chat with @bcaimano )

Another option would be to just log the memory address of the isolate itself but the requirement here is that the uniqueness be relatively guaranteed for the lifetime of the process, which we can't guarantee with the pointer address. We could also use a simple counter but that would likely require a lock. lazily creating the uuid here seems Good Enough (tm).

[bcaimano]

Thank you for getting to this so quickly!

So I'm trying to conceive of how I'd get this uuid to the metrics/observer system since they usually try to avoid taking the isolate lock. It feels like the IsolateObserver would be the most natural place, but that is constructed before the isolate. Perhaps we want to optionally take a uuid in isolate construction so that we could give it to both observer and isolate? We do naturally take the isolate lock immediately after construction, so I could see a world where we just stash it in other metrics types with a setter. I could also see something like tryGetUuid() that doesn't require the lock but returns a maybe. What do you think?

[jasnell]

Exposing on js::Lock is just a convenience for some cases. You can get the uuid without acquiring the lock by going directly to IsolateBase... e.g. IsolateBase::from(isolate).getUuid()

[bcaimano]

Hmmmm, looks like there is a compile failure for the test? Seems like a silly thing with type naming though.

I think this will serve well enough for me to start trying to use it for metrics, thank you!

[jasnell]

Yeah I'll fix that test up in a bit. Can you look at the internal PR also so I can get this landed once CI comes up green?