…gets

…ion with traits

1. Use type aliases to define state field types (for use outside the state module).
2. std::sync::Mutex -> parking_lot::RwLock (parking lot and rw lock are more efficient)

…interact with eachother.

…turns a cache reference

…tChanged event

…can not be poisoned; impl Debug on the Operation type

These are conceptually separated by being direct *internal* events that modify Odilia's state.
As opposed to events, which are generally recieved from the outside.

Also adds a few more Defualt implementations.

…odifiable state view

…aining ones

…sed in a synchronous context

…the Command structure.

…tween enum command variants

…ePrimitive> (the cache key)

It turns out we need async locking primitives, which at this time can not be compiled for any WASM architechture.
This restriction *should* be able to be lifted in the future, especially with the rise of two features:

1. An asyncronous WASM standard.
2. Reference types in WASM.

With both these features implemented, it is reasonably likely that no (de)serialization would have to be performed at all, and plugins could simply use the types as if they were a native Rust function.
This functionality, or event standardization is likely to take over a year, so I'm not holding my breath out for it, but when it comes, we should move the more advanced caching types back into odilia_common, and allow plugins free access to the cache, and maybe event the entire state, completely by reference.

Most operation in Odilia need to be done as an "atomic grouping" if you will.
For example, suppose two events come in: the first sets some new text, the second moves the cursor over the newly inserted word.
Although in reality it will be *incredibly* rare that these two events happen fast enough for Odilia to have this problem, in theory the section of text to speak could be processed before the write is complete from the first event.

Overall, I'm just trying to make sure that if Odilia is going to have synchronization errors, at least they will be contained to receiving the events in the wrong order, and not ones self-imposed.

* This was originally syncified because DashMap did not require any locks.
* Then, we even started to use a `parking_lot::Mutex`, which did not error when a lock attempt was made.
* But here, we need to asyncify the internal `tokio::sync::Mutex` on each individual cache item.
* This is because we want to use async in the rest of the codebase, and specifically we want to asyncronize separate event processing *by the locks made on these cache items*.

All traits that implement any functioanltiy (as opposed to traits that only specify types), should always be async.
An MVP was created without async available, but now it's time to bring it into the light :)