Statically linked Linux platform for plugins

[itowlson]

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.

[itowlson]

cc @jandubois for visibility

[lann]

I don't know that there is a standard label for statically linked artifacts. The rust equivalent is target-feature=+crt-static; by analogy we could have a set of "target features" on each PluginPackage (default empty) and have statically-linked spins "prefer" packages marked as statically linked while dynamically-linked spins "prefer" packages without that feature, and encourage plugin maintainers to publish both for Linux. Seems somewhat unavoidably messy...