Is your feature request related to a problem? Please describe

Hi there! I am opening this feature request to gauge ideas and comments about out-of-tree Pyodide builds, i.e., wasm32 wheels via the Emscripten toolchain for statsmodels. In my most recent work assignment, I am working on improving the interoperability for the Scientific Python ecosystem of packages with Pyodide and with each other, which shall culminate with efforts towards bringing interactive documentation for these packages where they can then be run in JupyterLite notebooks, through nightly builds and wheels for these packages pushed to PyPI-like indices on Anaconda, at and during a later phase during the project.

It looks like in-tree builds in the Pyodide have been built in the past as noted by the conversations in #7956 – and they seem to be maintained with every release for Pyodide. However, this issue proposes out-of-tree builds for statsmodels on its own CI and build infrastructure. I would be glad to work on this for statsmodels.

Describe the solution you'd like

1. A CI pipeline on Azure Pipelines or GitHub Actions (I would prefer the latter, but I have no qualms with the former) where Emscripten/Pyodide builds for the development version of statsmodels are pursued
2. Testing the built wheels against a Pyodide wasm32 runtime virtual environment within the same workflow
3. Fixing up and skipping failing tests as necessary based on current Pyodide limitations and ensuring that all relevant test cases pass

Describe alternatives you have considered

N/A

Additional context

This project is being tracked at Quansight-Labs/czi-scientific-python-mgmt#18 and has started out with packages like PyWavelets (PyWavelets/pywt#701) and NumPy (numpy/numpy#25894) being complete, thanks to @rgommers. Other packages besides statsmodels, such as matplotlib, zarr, pandas, and many more are planned to follow suit soon in the coming months.