New Python bindings for Yrs

[davidbrochart]

I created a new library called pycrdt, similar to Ypy but with a different approach.
Ypy is a Rust-only project, there is no Python file. While this ensures maximum performance, it also raises the level of complexity in my opinion. PR #117 was a significant amount of work, just to upgrade to a new version of Yrs. I think this is partly due to the fact that we are trying to do some things in Rust that would be easier to do in Python. Actually, the complexity of Ypy was my first motivation to start something else.
pycrdt is a mixed Python/Rust project. The Python bindings to Rust represent the minimum interface that allows to get things in and out of Yrs, and the higher-level logic is done in Python. This probably comes with a performance cost, as the Python/Rust boundary is crossed more often, but I'm not even sure it is noticeable (it would have to be benchmarked).
In the end, I think pycrdt is more pythonic, although maybe the same API could be implemented on top of Ypy. But most importantly, I think it is more approachable and it would be easier to contribute. I'm also thinking about new features that could be implemented, like transaction rollback or async support.
I think Ypy and pycrdt can coexist, as they take two opposite directions. Ypy is definitely more battle-tested, while pycrdt is very early stage. But I wanted to post this for awareness and to get feedback from the community.
cc @stefanw @Waidhoferj @dmonad @Horusiath

[Horusiath]

Tbh. I've never wrote that, but discussed on multiple occasions: my experiences after working with ywasm confirm that trying to keep language bindings in idiomatic fashion using only capabilities of Rust library (being it a pyo3 or wasm-bindgen) is very cumbersome.

It feels much more natural to have a 2-way split:

1. Rust bindings that only expose direct Yrs API into Python language (a.k.a. the sys/core lib).
2. Python code that implements the user-facing API and takes care of making it language-idomatic and improving user experience.

pycrdt goes this way, so did yrb and in the future I plan for ywasm to also embrace this approach.

I don't mind to see how this project unfolds, and depending on its maturity I don't mind the possibly of merging pycrdt into main branch of ypy - this will depend on the contributors, liveness and user engagement in both projects.