ENH Use dist-info + `importlib.metadata` to store and retrieve package metadata. This switches to using the file system to store the information about packages
and using `importlib.metadata` to retrieve it.
This has two related benefits:

1. We don't have to separately maintain our own separate state about what
we've installed.

2. We are guaranteed to agree with the Python stdlib about whether or not a
package is installed, and if so which version is installed. Since the state is 
maintained in only one place, there is no chance of it diverging.

According to the packaging specs, if the package is from a url we should put 
that into a file here:
https://packaging.python.org/en/latest/specifications/direct-url/#direct-url
Other than that, we should set the `INSTALLER` to `pyodide.loadPackage` 
if the package was loaded with `pyodide.loadPackage` either directly or 
indirectly via `micropip`. Otherwise set `INSTALLER` to `micropip`. That
way we can maintain the current behavior of `micropip.list`:
1. if `direct_url.json` is present, then `source` is the url in `direct_url.json`
2. otherwise, set `source` to `pyodide` if `INSTALLER` is `pyodide.loadPackage`
and set it to `micropip` if `INSTALLER` is `micropip`.

Oddly enough, the packaging specs suggest no place to put the source
index, so it seems that according to the specs if a package was installed
by name from some custom index, this info should not be recorded.

### Checklists

- [x] Add a [CHANGELOG](https://github.com/pyodide/pyodide/blob/main/docs/project/changelog.md) entry
- [x] Add / update tests

# core/pyodide

The C and JavaScript code in this package is responsible for embedding the
Python interpreter in our emscripten js/wasm application. The primary purpose of
this code is to define the foreign function interface between Python and
JavaScript. Once this foreign function interface is defined, more complex
behaviors are better defined in Python when possible for easier development and
debugging.

In particular, when possible logic should be moved from core/pyodide to
py/\_pyodide or to py/pyodide.

The core/pyodide code is responsible for the following main steps:

1. Initialize the CPython interpreter
2. Import py/\_pyodide
3. Initialize `_pyodide_core` which is a Python C extension that we use to make
   functionality available to py/pyodide.
4. Set up functionality to automatically convert functions from JavaScript to
   CPython calling conventions (`error_handling.h`).
5. Set up the "hiwire" side table to hold references to JavaScript objects --
   necessary because wasm variables can only hold numbers (`hiwire.c`).
6. Set up type conversions of basic types between Python and JavaScript
   (`js2python.c` and `python2js.c`).
7. Set up Proxying of remaining types between Python and JavaScript (`jsproxy.c`
   and `pyproxy.c`). This is the most complicated part of the Pyodide runtime
   and involves careful conversion between [abstract JavaScript object
   protocols](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)
   (see also [JavaScript Iteration
   Protocols](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols)
   )
   and [Python object protocols](https://docs.python.org/3/c-api/abstract.html).
8. Add `_pyodide_core` to `sys.modules` and import py/pyodide.

# core/pyodide

The C and JavaScript code in this package is responsible for embedding the
Python interpreter in our emscripten js/wasm application. The primary purpose of
this code is to define the foreign function interface between Python and
JavaScript. Once this foreign function interface is defined, more complex
behaviors are better defined in Python when possible for easier development and
debugging.

In particular, when possible logic should be moved from core/pyodide to
py/\_pyodide or to py/pyodide.

The core/pyodide code is responsible for the following main steps:

1. Initialize the CPython interpreter
2. Import py/\_pyodide
3. Initialize `_pyodide_core` which is a Python C extension that we use to make
   functionality available to py/pyodide.
4. Set up functionality to automatically convert functions from JavaScript to
   CPython calling conventions (`error_handling.h`).
5. Set up the "hiwire" side table to hold references to JavaScript objects --
   necessary because wasm variables can only hold numbers (`hiwire.c`).
6. Set up type conversions of basic types between Python and JavaScript
   (`js2python.c` and `python2js.c`).
7. Set up Proxying of remaining types between Python and JavaScript (`jsproxy.c`
   and `pyproxy.c`). This is the most complicated part of the Pyodide runtime
   and involves careful conversion between [abstract JavaScript object
   protocols](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)
   (see also [JavaScript Iteration
   Protocols](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols)
   )
   and [Python object protocols](https://docs.python.org/3/c-api/abstract.html).
8. Add `_pyodide_core` to `sys.modules` and import py/pyodide.
