actions/plugins/release-please is not usable by external developers — refactor or scope as internal

## Summary

The `actions/plugins/release-please` composite action was added in #322 with the stated intent to "Allow plugin developer to use googles release-please library without having to request a github app." However, the current implementation is only usable by Grafana Labs maintainers — not by external community plugin developers.

## The contradiction

The action requires:

1. Access to the Grafana \`ops\` Vault instance (\`grafana/shared-workflows/actions/get-vault-secrets\`) to fetch credentials for the \`plugins-platform-bot-app\` GitHub App.
2. The \`plugins-platform-bot-app\` GitHub App itself, which is only installed on Grafana-org repositories.

A community developer who follows \`examples/extra/release-please.yml\` and runs \`uses: grafana/plugin-ci-workflows/actions/plugins/release-please@plugins-release-please/v1.0.1\` on a non-Grafana repo will hit a Vault auth failure with no clear next step.

## Why it exists this way

The reason the action wraps a GitHub App at all (instead of using \`secrets.GITHUB_TOKEN\` directly) is the well-known GitHub Actions limitation: events triggered by \`GITHUB_TOKEN\` do not trigger new workflow runs. So a tag push made by release-please using \`GITHUB_TOKEN\` would not fire a downstream \`release.yml\`. The GitHub App workaround sidesteps this.

## Suggested fix: refactor to generic, with Grafana auth as opt-in

1. Add a \`token\` input to the action, defaulting to \`\${{ github.token }}\`.
2. Make the Vault + create-github-app-token steps **optional** — either gated behind a \`use-grafana-bot\` input flag (default \`false\`), or factored into a thin Grafana-specific wrapper composite that calls this one.
3. Document the trade-off in the action description: with \`GITHUB_TOKEN\`, tag pushes from release-please will not trigger downstream workflows. Workarounds: trigger your follow-on workflow on \`release: published\` instead of tag push, or supply your own GitHub App token via the \`token\` input.

This delivers on the original PR's promise (\"without having to request a github app\") for community developers, while keeping the one-line \`uses:\` ergonomics for Grafanistas.

## Alternative: scope honestly as internal

If the action is intended to be Grafana-internal only, rename it (e.g. \`actions/plugins/release-please-grafana\`) and add a clear \"for Grafana Labs internal use\" notice to the action description. Point external users at upstream \`googleapis/release-please-action\` directly. Less work, but doesn't match the original PR description.

## Context

Encountered this while migrating \`grafana/grafana-cube-datasource\` from \`version-bump-changelog\` to release-please (see grafana/grafana-cube-datasource#319). The action worked perfectly for me because I'm a Grafanista — but it took some thought to realise that the same example file, copied by an external developer, would fail. PR #710 here improved the example for Grafanistas but didn't fix the underlying scoping issue.

cc @L2D2Grafana @xnyo