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

[cdecker]

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.