Adopt uv workspaces and fix readme.md

[river-studio-main]

Summary

This PR adopts uv workspaces project structure and uv's build system as default, and fixes the readme section for local package development for contributors.
Addresses parts of: #119

Checklist

• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes.
• This PR fixes an issue.
• This PR adds something new (e.g. new method or parameters).
  • This change has an associated test.
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[AdrienVannson]

Thank you, I've considered using uv workspaces but I'm not sure if it is a good idea. The problem is that it forces to use the same Python environment for both the library and the compiler, which can lead to unexpected problems.

Sometimes, adding a new functionality requires a breaking change in the generated code. To implement it, it is often needed to do several steps of "changing something in the library" and "changing something in the compiler". At each step, it's convenient to recompile the test files and run all the tests.

However, the compiler relies on the library to decode the data sent by protoc. If a breaking change was made in the library, the compiler will not work until you regenerate the files it internally uses... But you can't do it easily since you need the compiler to work to generate these files.

For this reason, I think it's easier to pin the version of the lib used by the compiler while developing, and perform the update of the compiled files used by the compiler only at the end when everything is ready. As far as I know, you can't do that with an uv workspace.