Add opinionated `--grafanista` mode to `create-plugin` for Grafana Labs plugin defaults

## Summary

The default \`create-plugin\` template gives community developers a minimal \`release.yml\` and assumes manual \`npm version patch && git push --follow-tags\` for releases. That's a sensible default for the wide community audience.

But Grafana Labs plugin teams maintain a more opinionated stack on top — release-please for changelog/version automation, \`build-plugin\` with the platform bot for signed artifacts, \`publish.yaml\` for catalog deployment, etc. Each team rediscovers this independently when scaffolding a new plugin or migrating an existing one.

## Proposal

Add a \`--grafanista\` (or similarly-named) flag to \`create-plugin\` that scaffolds the opinionated Grafana Labs stack alongside (or instead of) the basic template. Likely contents:

- \`release-please.yml\` workflow + \`release-please-config.json\` + \`.release-please-manifest.json\` (with bump-minor-pre-major / include-component-in-tag: false defaults that match how Grafana plugins are typically released)
- \`release.yml\` that auto-publishes the GitHub release with the matching CHANGELOG.md section as the body and \`--latest\` (the pattern recently developed in [grafana/grafana-cube-datasource#323](https://github.com/grafana/grafana-cube-datasource/pull/323))
- Whatever else is part of the standard Grafanista stack (publish.yaml to catalog, etc.)

## Why opt-in, not default

The opinionated stack relies on Grafana-internal infrastructure — most notably the \`plugins-platform-bot-app\` GitHub App, which is only installed on Grafana-org repos. The current default template is the right behavior for community developers who don't have access to that. (See also [grafana/plugin-ci-workflows#713](https://github.com/grafana/plugin-ci-workflows/issues/713) where this scoping issue is discussed for one of the underlying actions.)

## Open questions

- Which team owns this? \`create-plugin\` lives here in plugin-tools, but the release-please workflow, the platform bot, and the auto-publish step are owned by plugins-platform / catalog teams. Realistically this might end up with platform-productivity if neither plugins-platform nor plugin-tools picks it up.
- Should the flag scaffold *additional* opinionated bits beyond release-please (e.g. the publish-to-catalog flow, default CODEOWNERS, default Vault paths, etc.)?
- Is \`--grafanista\` the right surface, or would a separate \`create-grafana-plugin\` package / a config preset be a better fit?

## Context

Came up while hardening \`grafana/grafana-cube-datasource\`'s release flow. Each Grafanista who scaffolds a plugin currently re-invents this stack — a non-trivial amount of duplicate effort that an opt-in default would absorb.