Add interactive playground for users to try rustworkx

[IvanIsCoding]

Follow up combining #1420 and the wheels built on #1449. Edit: the diff is now smaller; we use pre-built wheels from pyodide-recipes

This PR:

• Introduces jupyterlite-sphinx and jupyterlite-pyodide-kernel as dependencies
• Creates a playground page with rustworkx, users can run it in the browser
• The playground uses Pyodide from a CDN, Jupyterlite assets (around 16MB), and a rustworkx wheel that is from the Pyodide index

[IvanIsCoding]

Here's a look at the preview:

We could come with more ideas for the demo to auto-execute. Moreover, we could start adding more interactive snippets throughout the documentation

I reverted to this state to keep the playground cleaner.

I think we could add an interactive Matplotlib section in a seaparate place. Maybe we could even have a page that interacts with Graphviz via https://www.npmjs.com/package/@hpcc-js/wasm-graphviz + Pyodide.

[IvanIsCoding]

This is not ready yet, but upon thinking:

• I will try to make this depend on Add Pixi workflow to verify Pyodide build works #1449
• There will be an environment variable: if the variable is set, we enable the interactive playground. If it is not, we ignore the page and jupyterlite-sphinx
• For deployment to rustworkx.org and rustworkx.org/dev, we'll need to chain the Pixi workflow to the docs. Essentially, it will first build the WASM extension and then publish the docs

This way, we can avoid manually having to update the binary. We also won't have to check it in our Git tree.

[IvanIsCoding]

For the record: I am planning on re-working this PR as rustworkx is now shipped as a Pyodide recipe and the wheel can be installed with micropip:

We'll no longer have a binary.

[IvanIsCoding]

Nice this is working without the vendored file:

[mtreinish]

This will be pretty cool to have in the docs. Just a couple questions inline

[mtreinish]

I might have asked this before but is there a path to building the correct package as part of the docs build? It's not like a rustworkx build takes us that long and we already do it a bunch in CI. So we could then have different versions bundled for each docs build so it always matches.

Looking at the recipe you contributed to pyodide: https://github.com/pyodide/pyodide-recipes/blob/main/packages/rustworkx/meta.yaml it doesn't seem too complicated.

[IvanIsCoding]

So, I think the path to have the latest commit from main in is to:

1. Merge Add Pixi workflow to verify Pyodide build works #1449
2. Chain nox -edocs with the wheel built from pixi run build_pyodide

I think the biggest blockers are that #1449 uses Rust nightly (well, not quite but RUSTC_BOOTSTRAP is almost that with a pinned rustc). Moreover, setting up emscripten is a ritual that I will only accept in CI with some tool like pixi or nixpkgs. It needs a lockfile in my opinion, too many parts can break