Allow plugins to report their own version and store it in the registry

[devyn]

Description

This allows plugins to report their version (and potentially other metadata in the future). The version is shown in plugin list and in version.

The metadata is stored in the registry file, and reflects whatever was retrieved on plugin add, not necessarily the running binary. This can help you to diagnose if there's some kind of mismatch with what you expect. We could potentially use this functionality to show a warning or error if a plugin being run does not have the same version as what was in the cache file, suggesting plugin add be run again, but I haven't done that at this point.

It is optional, and it requires the plugin author to make some code changes if they want to provide it, since I can't automatically determine the version of the calling crate or anything tricky like that to do it.

Example:

> plugin list | select name version is_running pid
╭───┬────────────────┬─────────┬────────────┬─────╮
│ # │      name      │ version │ is_running │ pid │
├───┼────────────────┼─────────┼────────────┼─────┤
│ 0 │ example        │ 0.93.1  │ false      │     │
│ 1 │ gstat          │ 0.93.1  │ false      │     │
│ 2 │ inc            │ 0.93.1  │ false      │     │
│ 3 │ python_example │ 0.1.0   │ false      │     │
╰───┴────────────────┴─────────┴────────────┴─────╯

cc @maxim-uvarov (he asked for it)

User-Facing Changes

• plugin list gets a version column
• version shows plugin versions when available
• plugin authors should add fn metadata() to their impl Plugin, but don't have to

Tests + Formatting

Tested the low level stuff and also the plugin list column.

After Submitting

• update plugin guide docs
• update plugin protocol docs (Metadata call & response)
• update plugin template (fn metadata() should be easy)
• release notes

[fdncred]

I think it's a great idea to have plugin metadata for version and other potential stuff but I'm on the fence about making it optional. If someone wants to rely on it and it's optional, it makes it not as helpful because people can opt-out.

[devyn]

I can design the rust API to make it required then, e.g. with a fn version() For others it should be obvious because they'll have to implement Metadata.

[fdncred]

I could be wrong, but I think that sounds better.

[devyn]

I think this does that, then. The fn version(&self) -> String is required to be implemented in Rust, but it's technically an optional field still as far as the protocol goes.