Investigate new micropip features

### Problem

We still carry a lot of patches, managed as full-fat wheel builds, #27 adds _more_.

### Proposed Solution

Investigate whether new micropip features make this more reasonable.

- [ ] [`micropip.add_mock_package`](https://micropip.pyodide.org/en/v0.3.0/project/api.html#micropip.add_mock_package)
- this may allow moving heavyweight wheels to simple JSON descriptions
- unknown whether this properly ignores packages known to need to ship with multiple versions mocks, e.g. `widgetsnbextension {x|y}`
- special cases could potentially be detected and overridden
- [ ] [`micropip.install(..., index_urls)`](https://micropip.pyodide.org/en/v0.4.0/project/api.html#micropip.install)
- presumably these are still clobbered by `pyodide-lock.json`
- would need to decide how any configured settings would interact with direct calling with e.g. `%pip`
- [x] [`loadPyodide`](https://pyodide.org/en/stable/usage/api/js-api.html#globalThis.loadPyodide) options
- [x] `lockFileURL`
- fully replaces the default of the default `${indexUrl}/pyodide-lock.json`
- using existing known URLs, this could be used to generate a new composite lock file a given upstream
- theoretically could be done at runtime with a `data:` URI (unknown)
- _getting_ valid package descriptions still blocked by https://github.com/pyodide/pyodide-lock/issues/9
- [x] `packages`
- presumably these are the distribution names as found in the lock file
- generally won't work for complex dependencies that do need patching as above
- could add an advisory `--pyodide-preload-packages-blocklist` for kernel deps
- for the special case of notebooks, the list of required modules could be read from metadata

### Additional context

extracted from #39