Not intending to merge this. It supports my development environment on
NixOS where deps like Node from Volta that dynamically link to a glibc
interpreter are not executable.

This introduces a new `Signal.Volatile` function. It follows the initial
proposal here: tc39/proposal-signals#237

Volatile sources bring outside data into the computation graph.

If volatile sources are given a subscriber and the source is being
watched, now it returns from cache instead of querying `getSnapshot`
every time `source.get()` is invoked.

This only applies while being observed. When not observed, it fetches
from the snapshot function every time.

This causes the cache of `Signal.Computed` to be ignored and always
re-evaluate if it depends on volatile sources. We have to do this
because we don't know if the underlying sources changed since the last
time it evaluated.

When a volatile source upgrades to non-volatile (or is removed from the
dependencies list), the downstream consumers can once again cache their
evaluations.

When a volatile signal is upgraded to a tracked source through
`subscribe` it gets an `onChange` handler. Until this commit it was
a no-op. Now the `onChange` handler causes consumers to mark the current
value as dirty.

There are currently no restricted contexts for `onChange`. It's
conceivable we may want to restrict it.

Now volatile signals can depend on other signals inside `getSnapshot`.
Is this desirable? I'm not sure yet, but without supporting it, there
are unexpected edge cases. This is where the abstraction begins to leak
a bit.