Experiment: evaluate plugin/extension architectures

[OrlovEvgeny]

Idea came up in Discord with @mostafa discussing how Sigma https://github.com/timescale/rsigma rule support could look in LynxDB.

Time-boxed spike to decide if and how LynxDB should support out-of-tree extensions. Reference: DuckDB extensions.

Approaches

• Compile-time registry - init() + build tags, custom binary. Zero overhead, no isolation, no runtime distribution.
• Wasm via wazero - pure-Go runtime, language-agnostic, sandboxed. FFI cost per call.
• hashicorp/go-plugin - gRPC-over-stdio, process isolation. RPC overhead, subprocess per plugin.
• stdlib plugin - likely disqualified (Linux/macOS, identical Go version + flags required).

ns/op per row, µs/op per batch, distribution story, isolation, dev experience, binary size impact, debuggability.

I see it as

experiments/extensions/
├── bench/
├── compile-time/
├── wasm-wazero/
├── go-plugin/
└── stdlib-plugin/