Syncs withgoodboy/tractor#311which is nowhere near ready and this approach didn't end up beingas straight forward as hoped. We're going to need a top level`Msg`-boxing type/protocol in `tractor` first...

Syncs withgoodboy/tractor#311which is nowhere near ready and this approach didn't end up beingas straight forward as hoped. We're going to need a top level`Msg`-boxing type/protocol in `tractor` first...

As per the long outstanding GH issue this starts our rigorous journeyinto an attempt at a type-safe, cross-actor SC, IPC protocol Boboop ->#36The idea is to "formally" define our SC "shuttle (dialog) protocol" byspecifying a new `.msg.types.Msg` subtype-set which can fullyencapsulate all IPC msg schemas needed in order to accomplishcross-process SC!The msg set deviated a little in terms of (type) names from the existing`dict`-msgs currently used in the runtime impl but, I think the namechanges are much better in terms of explicitly representing the internalsemantics of the actor runtime machinery/subsystems and theIPC-msg-dialog required for SC enforced RPC.------ - ------In cursory, the new formal msgs-spec includes the following msg-subtypesof a new top-level `Msg` boxing type (that holds the base field schemafor all msgs):- `Start` to request RPC task scheduling by passing a `FuncSpec` payload  (to replace the currently used `{'cmd': ... }` dict msg impl)- `StartAck` to allow the RPC task callee-side to report a `IpcCtxSpec`  payload immediately back to the caller (currently responded naively via  a `{'functype': ... }` msg)- `Started` to deliver the first value from `Context.started()`  (instead of the existing `{'started': ... }`)- `Yield` to shuttle `MsgStream.send()`-ed values (instead of  our `{'yield': ... }`)- `Stop` to terminate a `Context.open_stream()` session/block  (over `{'stop': True }`)- `Return` to deliver the final value from the `Actor.start_remote_task()`  (which is a `{'return': ... }`)- `Error` to box `RemoteActorError` exceptions via a `.pld: ErrorData`  payload, planned to replace/extend the current `RemoteActorError.msgdata`  mechanism internal to `._exceptions.pack/unpack_error()`The new `tractor.msg.types` includes all the above msg defs as well an APIfor rendering a "payload type specification" using a`payload_type_spec: Union[Type]` that can be passed to`msgspec.msgpack.Decoder(type=payload_type_spec)`. This ensures that(for a subset of the above msg set) `Msg.pld: PayloadT` data istype-parameterized using `msgspec`'s new `Generic[PayloadT]` fieldsupport and thus enables providing for an API where IPC `Context`dialogs can strictly define the allowed payload-datatype-set via typeunion!Iow, this is the foundation for supporting `Channel`/`Context`/`MsgStream`IPC primitives which are type checked/safe as desired in GH issue:-#365Misc notes on current impl(s) status:------ - ------- add a `.msg.types.mk_msg_spec()` which uses the new `msgspec` support  for `class MyStruct[Struct, Generic[T]]` parameterize-able fields and  delivers our boxing SC-msg-(sub)set with the desired `payload_types`  applied to `.pld`:  -https://jcristharif.com/msgspec/supported-types.html#generic-types  - as a note this impl seems to need to use `type.new_class()` dynamic    subtype generation, though i don't really get *why* still.. but    without that the `msgspec.msgpack.Decoder` doesn't seem to reject    `.pld` limited `Msg` subtypes as demonstrated in the new test.- around this ^ add a `.msg._codec.limit_msg_spec()` cm which exposes  this payload type limiting API such that it can be applied per task  via a `MsgCodec` in app code.- the orig approach in#311 was  the idea of making payload fields `.pld: Raw` wherein we could have  per-field/sub-msg decoders dynamically loaded depending on the  particular application-layer schema in use. I don't want to lose the  idea of this since I think it might be useful for an idea I have about  capability-based-fields(-sharing, maybe using field-subset  encryption?), and as such i've kept the (ostensibly) working impls in  TODO-comments in `.msg._codec` wherein maybe we can add  a `MsgCodec._payload_decs: dict` table for this later on.  |_ also left in the `.msg.types.enc/decmsg()` impls but renamed as    `enc/dec_payload()` (but reworked to not rely on the lifo codec    stack tables; now removed) such that we can prolly move them to    `MsgCodec` methods in the future.- add an unused `._codec.mk_tagged_union_dec()` helper which was  originally factored out the#311 proto-code but didn't end up working  as desired with the new parameterized generic fields approach (now  in `msg.types.mk_msg_spec()`)Testing/deps work:------ - ------- new `test_limit_msgspec()` which ensures all the `.types` content is  correct but without using the wrapping APIs in `._codec`; i.e. using  a in-line `Decoder` instead of a `MsgCodec`.- pin us to `msgspec>=0.18.5` which has the needed generic-types support  (which took me way too long yester to figure out when implementing all  this XD)!