This PR finishes adding types (partial types were added in #1592, #1593 did some prerequisite rearrangement).

To generate the types correctly in `pyproxy.js`, I changed the protocols like `PyProxyLengthMethods` into ES6 classes (they used to just be objects). This was needed because otherwise Typescript makes the protocol into a namespace but I want it to be a type to indicate that an object has certain methods. To compensate for this change, I had to modify `getPyProxyClass` accordingly. This change required a number of syntactical changes.

I also added a bunch of predicate methods to the base `PyProxy` class to test whether the proxy supports certain extra methods. These are needed to use as Typescript type guards, but they probably are also useful by themselves when code needs to do reflection on the proxies.

I don't know whether the exposed types or the type guard predicates are well named, I would be happy for recommendations of improvements to the names -- both the type names and the predicates are public and deserve to be named with care.

JsDoc does not recognize typescript type guards or typescript type definitions, so I added a JsDoc plugin which strips out type definitions and transforms typeguards `x is y` ==> `boolean`. There's one JsDoc typescript parse error that still happens but it doesn't cause any harm to the output.

I also changed the way that we collect javascript API docs to be a bit more robust. In particular, it used to be organized by file. I changed it as follows: 
1. any API part of `globalThis` or marked with `@memberof globalThis` is treated as a global, 
2. any API of a class whose name starts with `PyProxy` is treated as a part of the `PyProxy` API,
3. anything else is assumed to be part of the pyodide API

As before, things marked `@private` are left out.

I also added tests for the type declarations using `tpd`. They are a new CI step.


ENH More complete typescript types. This PR finishes adding types (partial types were added in #1592, #1593 did some prerequisite rearrangement).

To generate the types correctly in `pyproxy.js`, I changed the protocols like `PyProxyLengthMethods` into ES6 classes (they used to just be objects). This was needed because otherwise Typescript makes the protocol into a namespace but I want it to be a type to indicate that an object has certain methods. To compensate for this change, I had to modify `getPyProxyClass` accordingly. This change required a number of syntactical changes.

I also added a bunch of predicate methods to the base `PyProxy` class to test whether the proxy supports certain extra methods. These are needed to use as Typescript type guards, but they probably are also useful by themselves when code needs to do reflection on the proxies.

I don't know whether the exposed types or the type guard predicates are well named, I would be happy for recommendations of improvements to the names -- both the type names and the predicates are public and deserve to be named with care.

JsDoc does not recognize typescript type guards or typescript type definitions, so I added a JsDoc plugin which strips out type definitions and transforms typeguards `x is y` ==> `boolean`. There's one JsDoc typescript parse error that still happens but it doesn't cause any harm to the output.

I also changed the way that we collect javascript API docs to be a bit more robust. In particular, it used to be organized by file. I changed it as follows: 
1. any API part of `globalThis` or marked with `@memberof globalThis` is treated as a global, 
2. any API of a class whose name starts with `PyProxy` is treated as a part of the `PyProxy` API,
3. anything else is assumed to be part of the pyodide API

As before, things marked `@private` are left out.

I also added tests for the type declarations using `tpd`. They are a new CI step.


# 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.
