Consider Migrating to Rye

[`rye`](https://rye-up.com) is a newer, **rust** based tool for python management, inspired by `cargo`'s utility in the rust ecosystem.

It has tooling for
- Installing and managing python installations (like [`pyenv`](https://github.com/pyenv/pyenv))
- Project dependency management via `pyproject.toml` (like [`poetry`](https://python-poetry.org))
- Python tool / app global installation and isolation (like [`pipx`](https://pypa.github.io/pipx/))

It's designed to be:
- Matching as close as possible to [PEP 621](https://peps.python.org/pep-0621).
- As extensive as [`cargo`](https://doc.rust-lang.org/cargo/) is to rust.
- Removing all custom complexity (leveraging base `requirements` format for `.lock` files)

Since `rye` manages both python installations AND project management, it can **ensure** a correct python is being used for maintainers and contributors, a really key fact that trumps the current `poetry` setup. It also leverages a much simpler setup for dependency locking (using the same resolver as `pip`) and avoids bootstrapping issues (and gains speed) from being a **rust** project (instead of a python/shell tool).

## Considerations
I'm a bit hesitant to migrate this repo *again* from one project management tool to another, as a symptom of "shiny object syndrome". `rye` is also a newer tool, unlike `poetry`, and lacks a bit of the foundation (esp. from industry) that `poetry` has gained w/ experience overtime. The community resources is necessarily weaker (growing) and there will be growing pains if we did make this move. I've already ran into some small barriers of missing features from `poetry` in `rye`.

The main reason why I think it's a good idea is to really simplify the tooling we both use and [recommend](https://docs.playgrounds.network/subgrounds/faq/setup/), especially from the point of view of simplistic python installations that match for project development (won't harm whatever python situation you have going on). It specifically aims to never **compile** python to your system (unless you chose to) which fixes a whole load of issues with `pyenv`. Python installations vary so widely among systems that it can get a bit awkward to manage (w/ shell shims and global environments galore). I've seen this first hand with the struggle of getting a working `poetry` setup.

I've started using it for some personal projects and I've greatly enjoyed the simplicity in the design (for example, it outputs `requirements.lock` that can be `pip` installed naturally, making `Dockerfile`s and Github Action workflows simpler).

The issue proposes migrating the project's Python management from poetry to rye. Start by reading the rye documentation at rye-up.com and understanding the current project's pyproject.toml and lock files. Assess the changes needed in the CI/CD workflows (like GitHub Actions) and Dockerfiles. The goal is to ensure the project builds and tests pass with rye, and update the setup documentation accordingly.

Written by the indexing model from the issue text.