plugins: Flexible runtime and restricting plugins with `plugin-runner`

This issue describes an idea that has been floating around in the CLN
community for some time, and since it could provide a solution to some
common problems, I'll quickly describe the idea, and see what other
issues are addressable with it.

## Plugin execution

The `lightningd` main daemon starts each plugin as a subprocess, via
`execve`, then takes over the `stdout` and `stdin` file descriptors in
order to communicate with it.

The command being executed is either of the following:

- `["/path/to/plugin.exe"]`
- `["/path/to/plugin.exe", "--developer"]`

So control is passed directly to the plugin executable, and the
subprocess runs in the same user context, and with the same
permissions as `lightningd` itself.

## `plugin-runner`

The `--plugin-runner` option would add the ability to specify a
wrapper that should be used to isolate plugins from the parent
context.

This allows the creation of `plugin-runner` wrappers that open up a
wide range of possibilities:

- **Remote plugins**: the plugin runner could just be a stub that
exposes a (partial) RPC interface, and starts the plugin somewhere
remote (Kubernetes, `cgroup`, `docker`, central service...).
- **Unprivileged plugins**: the plugin does not get access to the
`lightning-dir` and its interactions with `lightningd` go through a
proxy RPC that is re-exposed by the wrapper in the plugin
context. This could be running in `docker` isolated via `chroot` or
running as an unprivileged user.
- **Policy enforcement on plugins**: the wrapper can enforce
arbitrary logic, including things that aren't expressible in runes.
- **Access control**: Limit to what runes permit you to do as a
separate layer.