feat(build): summer plugin:update

- module installs move to the newest compatible registry release with
  one go get; submodules fetch tags, check out the release tag and
  require it in go.mod; go.work overrides and version pins are refreshed
- unlisted submodules (git URL installs) update from their own tags and
  plugin.yaml; --offline restricts to that
- without an ID every plugin that resolves is updated; in-app, unlisted
  and incompatible ones are reported; failure only when a resolved
  update cannot be carried out
- same prompt rule as plugin:install

docs/architecture/go-modules-and-workspaces.md

@@ -121,7 +121,7 @@ A shared plugin's own `go.mod` usually replaces the framework, and sometimes sib
 - when the module is itself in the workspace (another plugin installed as a submodule), `go.work` replaces that module at its required version with its directory, such as `replace git.example.com/acme/translate v0.1.0 => ./plugins/acme/translate` (Go refuses a replace of a workspace module at all versions);
 - otherwise `go.work` pins the module to the version the application requires, such as `replace git.golem15.com/golem15/summercms => git.golem15.com/golem15/summercms v0.6.0`.
 
-A pin of the last kind follows the application: when the framework requirement in `go.mod` moves, the next submodule install moves the pin to the new version. Replaces you wrote into `go.work` yourself are left alone.
+A pin of the last kind follows the application: when the framework requirement in `go.mod` moves, the next `summer plugin:install` from source or `summer plugin:update` moves the pin to the new version. Replaces you wrote into `go.work` yourself are left alone.
 
 ## Replacing and forking a plugin