Future plugin system improvements

[dsherret]

• Send log level on initialize so plugins can output with verbose logging.
• Send past version with upgrade message (if not already done)
• Logging with log level in wasm plugins
• Ability for plugins to tell if no_color and if a tty. Probably send on init
• Maybe ability for Wasm plugin to import another wasm plugin via Wasm imports?
• Wasm schema should not require instantiating a wasm module (it should be figured out by just analyzing the import names)
• Ability for plugins to do comparisons with language aware algorithms (ex. for sorting imports).

[Phault]

I'm curious what your thoughts are on Extism? Would you ever consider switching out your current Wasm-plugin system, for something built on top of that instead?

As you mention yourself in the docs, there's a lot of low-level plumbing code to write, if you're not using the dprint-core crate. Being able to use the Extism Plug-in Development Kits would both reduce the amount of code needed, as well as not requiring low-level skills, thus significantly lowering the bar for creating new plugins.

Anecdotally I code in C# daily, but never actually touched interop code in it, so I was at a complete loss when trying to skaffold a new Wasm plugin in it. Admittedly I quickly gave up.

That said, I've had little exposure to Extism from the host side of things, and I've no idea how lightweight both sides are. There's also always the risk of abandonment, but it seems to have a thriving community behind it.