Statically linked Linux platform for plugins

At the moment plugins are distinguished only as Linux/Mac/Windows and x64/ARM.

Because of this, the static-linux build of Spin resolves to Linux and typically ends up trying to load dynamically linked plugins, which doesn't end well.

One proposal is that we should support a new "static Linux" OS type for plugins. Some careful timing would be needed here, because existing versions of Spin will be unable to parse a new OS string, and would likely end up failing to load the manifest altogether. And of course we can't make them more forgiving because they're already out there.

Another possible way is to add a new optional field to PluginPackage e.g. "linkage" or something more general. I believe (but haven't yet confirmed) that existing Spin is wisely tolerant of unknown fields in a plugin manifest. Statically linked builds could then take this into account.

We would also need a way for a Spin instance to determine if it should use the static plugin. But if we can't determine this dynamically then we can just inject an indicator at compile time.

A final possibility is to do nothing in Spin but to encourage plugin authors to link their Linux builds statically. Although this depends on my naive assumption that static builds can run anywhere that dynamic ones can. Come at me, vengeful hubris, I am ready for your scorn.

The issue names no files, tests, or entry points. Start by tracing plugin manifest parsing and how a static-linux Spin build selects plugins, then compare the proposed OS-type and optional-field approaches for compatibility with existing Spin versions. Done means an agreed design and a tested way for Spin to select compatible plugins.