Plugin manager refactoring

[itowlson]

This emerged from prototyping on #3494. The original plugin code was fairly simple and well structured, but over time it has accreted a bunch of stuff that bypasses abstractions and entangles concerns, to the point where I was struggling to figure out how and where to add some stuff I needed.

This PR aims to restore a division of responsibilities between:

• The Manager - the thing that applications interact with to list, install, remove, and execute plugins without needing to know internal implementation details
• The Store - the thing that knows how to lay files out on disk
• The Catalogue (new) - the snapshot of the remote spin-plugins repo - knows about available plugins and updating (although updating remains a slightly fuzzy responsibility, but that's not a huge concern for me)

I have made the store module private, so that application code is not tempted to perform logic directly against the disk layout: the manager should surface all that at a layer of abstraction that insulates the app from knowledge of JSON and directories and related nibbly bits.

I also did some minor renaming, and added some doc comments where I was struggling with names.

I don't imagine I've eliminated all the tangly bits, in fact I know some bits that still feel a bit of a lash-up (I think largely because of the badger), but for me this surfaces a clearer API to consumers of the crate. Feedback is, of course, welcome!

[itowlson]

CI failure is due to an unrelated change in the JS SDK (spinframework/spin-js-sdk#506) so I will bypass.