[Versioning] plugin module ends up with older dependency that sometimes causes interface mismatches

[IfSentient]

As part of our release process, we tag the current version with a vX tag, and the plugin submodule with a plugin/vX tag to keep versions in-sync. However, the plugin submodule has its own go.mod that depends on a specific version of the grafana-app-sdk, and which doesn't get changed until after the release, meaning it always is at least one version behind. When doing local development and building, this issue is not exposed because the go.work file has the plugin submodule use the local version of the main module, but when using them as dependencies in an app, the plugin submodule uses what's in its go.mod, which can lead to interface mismatches when minor versions change.

Th proper solution to this is to release the main module, bump the plugin go.mod version, then release the plugin module for that version.

[IfSentient]

I think the most expedient approach for this (given that the main branch is protected) that avoids requiring manual steps, would be to have the release GH action workflow cut a branch called something like plugin-release/<version> from the tagged commit, update the plugin's go.mod to use the tag version for grafana-app-sdk, and then create a plugin/<version> tag for the plugin release. The release script in scripts should then not also create the plugin release tag, relying on the action to do so.

The downside of this is that the action would need a GH account to use to make said push.

[IfSentient]

Actually, the best quick fix here (as a more complete solution would be part of #236) might be to have this done in the scripts/release.sh script instead, updating the plugin/go.mod and plugin/go.sum, cutting the branch, pushing the branch, and then creating and pushing the plugin/<version> tag.