:computer: Add support for IPC-backed plugins

[agoose77]

This PR fixes #1298 in a different way to #1325 by adding a new "executable" type of plugin (the approach taken in https://gist.github.com/agoose77/66700b2a172b4c11d4801f742534e4f7). Unlike #1325, this PR adds support for Python via an IPC mechanism (stdout, stdin).

1325 and this PR are not mutually exclusive; #1325 adds support for an in-process Python executor, which supports sharing stateful proxies between JS and Python. This PR, meanwhile, is fully decoupled and allows for further languages. Note that, unlike #1325, we do not vendor Python, so it is possible that users may define plugins whose environment is not sufficiently reproducible and thus see build errors.

[!NOTE]

1325 will need to be rebased and updated to use this new mechanism for declaring plugin types.

To implement such a plugin, the executable needs to support the following invocation modes:

• proc Return the "spec" of the plugin, i.e. the implementation-free plugin block
• proc --directive <DIRECTIVE> Execute the implementation of a directive <DIRECTIVE>
• proc --role <ROLE> Execute the implementation of a role <DIRECTIVE>
• proc --transform <TRANSFORM> Execute the implementation of a transform <DIRECTIVE> whereby the auxillary data for these executions is provided via stdin, the results read out from stdout, and error/debug information read from stderr.

Right now, I didn't add the validate method. We could; it's not much extra work. But do we need it? An example of a directive and transform is given in the docs of this PR.

[!CAUTION] Syntax Changes from this PR in myst.yml:

```yaml project: plugins: - test.mjs ```

```yaml project: plugins: - type: javascript path: test.mjs - type: executable path: python.py ```

N.b. this change is opt-in; existing plugin declarations will work just fine.

[rowanc1]

Can we auto detect that in the transform and expand plugin.py to the dict?

e.g.

project:
  plugins:
    - test.mjs
    - plugin.py

Which is basically what you wrote, but slightly nicer UX / overhead for the user. :)

[rowanc1]

Note that the way you wrote it should also work, as I see now the javascript could also be an executable.

[agoose77]

@rowanc1 yes, I think the forward-looking preferred syntax would be the verbose kind. For single strings, we should only support known extensions but IPC plugins don't have a specific extension. If we added support for Python as in #1325, then we'd be able to write

  plugins:
    - foo.mjs
    - bar.py

Otherwise, we expand non-.mjs plugins to executable plugins, and then down the road this breaks when we add support for e.g. .py.