This resolves #2189.

> build isolation would be a bit difficult to use in our case, as for instance when building scipy we need the patched numpy on the host and not the numpy version specified in pyproject.toml (which would be unpatched)

This is indeed the case, certain packages cannot be isolated. My strategy is to make a list of packages that shouldn't be isolated and add symlinks from the isolated build environment into the `.artifacts` directory to "unisolate" them. Then we remove the unisolated package requirements from the list of packages to install, in case pesky constraints aren't satisfied. In particular, packages that expect to be used with `pypa/build` often feel free to put very specific constraints on their build dependencies (often asking them to be == to a particular version). Specific version constraints is good for build reproducibility and with build isolation doesn't cost anything. So we just ignore the constraints. Hopefully nothing goes wrong.

In particular, any package that does stuff both at build time and at runtime and requires synchronization between the build time and run time environments needs the unisolation. This includes cffi with `_cffi_backend.so`, and of course numpy and scipy. pycparser needs to be unisolated because it is a dependency of cffi.

Currently I have also unisolated pythran and cython, though these are build time only tools and do not really need to be unisolated. Cython I unisolated specifically because numcodecs needs it but it isn't in the numcodecs build dependencies. Pythran I unisolated because of a problem with the scipy build which I don't fully understand (some problem with long double feature detection). I believe both of these are removable, particularly once #2132 is finished.
Use pypa/build. This resolves #2189.

> build isolation would be a bit difficult to use in our case, as for instance when building scipy we need the patched numpy on the host and not the numpy version specified in pyproject.toml (which would be unpatched)

This is indeed the case, certain packages cannot be isolated. My strategy is to make a list of packages that shouldn't be isolated and add symlinks from the isolated build environment into the `.artifacts` directory to "unisolate" them. Then we remove the unisolated package requirements from the list of packages to install, in case pesky constraints aren't satisfied. In particular, packages that expect to be used with `pypa/build` often feel free to put very specific constraints on their build dependencies (often asking them to be == to a particular version). Specific version constraints is good for build reproducibility and with build isolation doesn't cost anything. So we just ignore the constraints. Hopefully nothing goes wrong.

In particular, any package that does stuff both at build time and at runtime and requires synchronization between the build time and run time environments needs the unisolation. This includes cffi with `_cffi_backend.so`, and of course numpy and scipy. pycparser needs to be unisolated because it is a dependency of cffi.

Currently I have also unisolated pythran and cython, though these are build time only tools and do not really need to be unisolated. Cython I unisolated specifically because numcodecs needs it but it isn't in the numcodecs build dependencies. Pythran I unisolated because of a problem with the scipy build which I don't fully understand (some problem with long double feature detection). I believe both of these are removable, particularly once #2132 is finished.
# Sphinx-Pyodide

This package is a special sphinx extension for Pyodide's documentation.
The three separate files do three unrelated tasks:

## packages

Adds a custom directive which makes a table of the Pyodide packages

## lexers

Adds custom pyodide Pygments lexers that provides syntax highlighting for
Javascript with embedded Python code, and for HTML with embedded Javascript that
itself contains embedded Python.

e.g., in

```pyodide
await pyodide.loadPackage(numpy);
pyodide.runPython(`
    def f(y):
        return y + ${x}
    f(7)
`);
```

the code inside of `pyodide.runPython` is highlighted as Python, the other code
is highlighted as Javascript. Similarly with `html-pyodide`:

```html-pyodide
<div></div>
<script type="text/javascript">
console.log(pyodide.runPython(`
    import sys
    sys.version
`));
</script>
```

## jsdoc

This extends `sphinx-js` for our purposes. This contains a mix of missing
features that could ideally be upstreamed into `sphinx-js` and custom code that
can't be upstreamed.

### TsAnalyzer monkey patches

We monkey patch `TsAnalyzer._type_name` to fill in formatting of types that were
left as TODOs by `sphinx-js` (this could probably be upstreamed).

We monkey patch `TsAnalyzer._convert_node` to fix two crashes (could be
upstreamed) and to turn a destructured object argument into a list of argument docs:

```js
/**
* @param options
*/
function f({x , y } : {
    /** The x value */
    x : number,
    /** The y value */
    y : string
}){ ... }
```

should be documented like:

```
options.x (number) The x value
options.y (number) The y value
```

### `js:function`

We update the `js:function` directive to display `async` in front of async
functions.

### `PyodideAnalyzer`

We compose `TsAnalyzer` into `PyodideAnalyzer`. This prunes out private
functions, marks functions as `async` so we can display `async` in front of
them, and organizes functions into our three categories:

- `globalThis`: globaly exposed functions
- `pyodide`: pyodide APIs
- `PyProxy`: `PyProxy` APIs

It also classifies them into three types: function, class, or attribute so we
can separate them out in the summary.

### js-autodoc

`sphinx-js` doesn't include full recursive layout features by default. This adds
a `js-doc-summary` directive and a `js-doc-content` directive. `js-doc-summary`
makes a summary table for any category (`globalThis`, `pyodide` or `PyProxy`)
and `js-doc-content` formats the main documentation content. These are used in
`js-api.md`. A lot of this code is similar to the `autosummary` package, but
there are enough differences that it was easier to copy the code in.

## autodoc_submodules

This makes autodoc recursively document submodules, mixed in with the top level
docs. For instance, `pyfetch` is defined in `pyodide.html`. This adds an entry
called `http.pyfetch` to the list of documented APIs for `pyodide`.

# Sphinx-Pyodide

This package is a special sphinx extension for Pyodide's documentation.
The three separate files do three unrelated tasks:

## packages

Adds a custom directive which makes a table of the Pyodide packages

## lexers

Adds custom pyodide Pygments lexers that provides syntax highlighting for
Javascript with embedded Python code, and for HTML with embedded Javascript that
itself contains embedded Python.

e.g., in

```pyodide
await pyodide.loadPackage(numpy);
pyodide.runPython(`
    def f(y):
        return y + ${x}
    f(7)
`);
```

the code inside of `pyodide.runPython` is highlighted as Python, the other code
is highlighted as Javascript. Similarly with `html-pyodide`:

```html-pyodide
<div></div>
<script type="text/javascript">
console.log(pyodide.runPython(`
    import sys
    sys.version
`));
</script>
```

## jsdoc

This extends `sphinx-js` for our purposes. This contains a mix of missing
features that could ideally be upstreamed into `sphinx-js` and custom code that
can't be upstreamed.

### TsAnalyzer monkey patches

We monkey patch `TsAnalyzer._type_name` to fill in formatting of types that were
left as TODOs by `sphinx-js` (this could probably be upstreamed).

We monkey patch `TsAnalyzer._convert_node` to fix two crashes (could be
upstreamed) and to turn a destructured object argument into a list of argument docs:

```js
/**
* @param options
*/
function f({x , y } : {
    /** The x value */
    x : number,
    /** The y value */
    y : string
}){ ... }
```

should be documented like:

```
options.x (number) The x value
options.y (number) The y value
```

### `js:function`

We update the `js:function` directive to display `async` in front of async
functions.

### `PyodideAnalyzer`

We compose `TsAnalyzer` into `PyodideAnalyzer`. This prunes out private
functions, marks functions as `async` so we can display `async` in front of
them, and organizes functions into our three categories:

- `globalThis`: globaly exposed functions
- `pyodide`: pyodide APIs
- `PyProxy`: `PyProxy` APIs

It also classifies them into three types: function, class, or attribute so we
can separate them out in the summary.

### js-autodoc

`sphinx-js` doesn't include full recursive layout features by default. This adds
a `js-doc-summary` directive and a `js-doc-content` directive. `js-doc-summary`
makes a summary table for any category (`globalThis`, `pyodide` or `PyProxy`)
and `js-doc-content` formats the main documentation content. These are used in
`js-api.md`. A lot of this code is similar to the `autosummary` package, but
there are enough differences that it was easier to copy the code in.

## autodoc_submodules

This makes autodoc recursively document submodules, mixed in with the top level
docs. For instance, `pyfetch` is defined in `pyodide.html`. This adds an entry
called `http.pyfetch` to the list of documented APIs for `pyodide`.
