atrium-streams + atrium-streams-client implementation

[oestradiol]

This Pull Request adds two new crates:

• atrium-streams: Definitions for traits, types and utilities for dealing with event stream subscriptions.
• atrium-streams-client: A library that provides default implementations of the EventStreamClient, Handlers and Subscription defined in atrium-streams for interacting with the variety of subscriptions in ATProto.

TODO:

• - Implement processing of other payload types for Firehose implementation + add configurations to manually enable payload types to avoid unnecessary computations;
• - Write unit tests;
• - Implement other subscriptions, such as com.atproto.label.subscribeLabels + tests;
• - Implement an alternative client for codebases that do not use Tokio as an asynchronous runtime + tests.
• - Create crate features so that users can deactivate specific features;
• - Write CHANGELOG.md and README.md;
• - Write Github Workflows for both crates + test features;
• - Prepare for wasm target;
• - Using std::mem::transmute is not recommended. It works wonderfully for now, but eventually it might not anymore. Think of a way to replace the outdated rs_car crate somehow (if possible).

[oestradiol]

Obs.: Refer to #223 for information on name choices, as well as why this Draft was re-created.

[oestradiol]

Force-pushed to re-sync with main.

@sugyan, it seems giraffate/clippy-action@v1 is not causing the workflow to fail whenever there is an error:

• https://github.com/sugyan/atrium/actions/runs/10949150569/job/30401745143?pr=228#step:6:43
  This specific occurrence was not caused by this branch but by code that was on main.

Is this expected behaviour?

[sugyan]

I'm not sure since I can't see that event from your link, but it may indeed just be reported and not fail.

I didn't really think much about what should happen at first when I installed it. Now I think... it doesn't have to follow strictly and Not Fail is the expected behavior.