When looking for upgradeable installed plugins, check only on name

[itowlson]

Fixes #3124

This addresses a situation where a plugin is in the registry, but a user has a plugin version that is not in the plugins registry (such as a canary or preview release installed from a URL). Such a plugin can be upgraded using an explicit name (spin plugins upgrade befunge2wasm), but is not displayed in the multiselect experience (spin plugins upgrade with no arguments). This is surprising and unhelpful - especially since the badger does detect the available upgrade and tells the user about it.

The incorrect behaviour occurs because the "which installed plugins have upgrades" routine starts by looking for installed plugin manifests which also appear in the registry. For a version that was never in the registry, that check fails, so the plugin is not even checked for upgradability. The correct check is likely on "which installed plugin names also appear in the registry." This seems to align with badger and named upgrade behaviour.

The existing behaviour does not seem to be by design - I can find no discussion on the original PR arguing for why full manifest match rather than name match. So I don't think we'll be breaking any assumptions by aligning the multiselect to the name check.

Come at me, Hubris, I'm ready.

[itowlson]

The integration test failure is because a jco update broke the JavaScript SDK (spinframework/spin-js-sdk#362) - I will force bypass.