Start importing model stream logic

[PaulLeCam]

Hey @ukstv @stbrody can you let me know what you think of the approach to implement stream types here?

I made the separation between 3 packages:

• stream-model provides the codecs and "local" (no need for HTTP client or other I/O) validation functions, maybe we could name it stream-model-protocol if it's more explicit?
• stream-model-client handles the client-side logic of creating model streams, by creating the signed event and performing the "local" validation. The idea is that the signed event can then be encoded to CAR and sent to rust-ceramic using the HTTP client directly if wanted.
• stream-model-handler handles the server-side validation of the model events, by running the "local" validation functions, but also the validation of interfaces which requires being able to load other models. This ability must be provided by the consumer.

I'm refactoring a bunch of the logic when importing the code from js-ceramic, mainly to remove any dependency on @ceramicnetwork/common. Only @ceramicnetwork/codecs and @ceramicnetwork/streamid are used so far, which I think is good considering they're unlikely to need changes.

If the direction looks OK to you, I'll start importing the tests to cover these packages.

[stbrody]

actually thinking about this more, I don't think the specific streamtype handler implementations belong in the ceramic-sdk monorepo or npm namespace. The Ceramic SDK should focus on reading and writing raw events. The aggregation library is something different than the ceramic-one sdk and should have its own monorepo and namespace I think