feat: Plugin system (#426)

[tedil]

This draft PR adds a plugin system based on extism (#426). To that end, the project is converted to a workspace with (currently) three members: mehari, mehari-plugins and mehari-plugin-vep-nmd.

• mehari remains unchanged
• mehari-plugins currently contains stubs mimicking VEP's tva data structure, while mehari-plugin-vep-nmd contains a translation of VEP's NMD plugin to rust code.
• mehari-plugin-vep-nmd has a different build-target (wasm32-unknown-unknown) than the other workspace members, and, as such, it has a corresponding .cargo/config.toml file.

However, workspaces do not support having different targets (yet), so cargo will build all workspace members for the default target. To actually get a WASM binary for the plugin, explicitly execute cargo build in the mehari-plugin-vep-nmd directory.
(Could probably be done with a Makefile or something similar, at least until the different-targets-per-workspace-member feature hits stable)

[tedil]

I added a little criterion benchmark comparing calling a compiled wasm plugin and doing the same* work natively, here are some first insights:

1. calling the NMD WASM plugin: 10µs / repeat
2. performing NMD annotation natively: 70ns / repeat
3. performing NMD annotation natively + artificially (de-)serializing and cloning the input data: 2µs

i.e. some time is spent on serde to/from json, some time is spent on cloning, some time is spent on WASM overhead I guess.