[Arthurk12]

What does this PR do?

Extends the "Cut a new tag" workflow (.github/workflows/publish-tag.yml) so that, besides package.json and package-lock.json, it also:

• sets the version(introduced in feat: Add prop version to plugins manifest to avoid browser caching bigbluebutton#24153) field of manifest.json to the bumped version, creating the field when it does not exist yet;
• prepends a new entry to CHANGELOG.md, when the plugin has one, following the heading level (##/###) and bullet style (*/-) already used in the file;
• prepends a new entry to debian/changelog, when the plugin has one, reusing the package name, distribution and maintainer of the previous entry.

The changelog entries are built from the commit subjects since the previous tag, skipping merge commits and previous chore: bump version to commits; when nothing is left, the entry is chore: release vX.Y.Z. If a changelog already has a hand-written entry for the new version, it is left untouched.

Version bump, manifest and changelogs land in a single chore: bump version to X.Y.Z commit, tagged vX.Y.Z and pushed as before.

Supporting changes:

• fetch-depth: 0 on checkout, so the history and tags needed to list commits since the previous release are available;
• permissions: contents: write on the job, so the push of the commit and tag is allowed;
• the single bump step is split into named steps, so each part shows up separately in the run log.

Closes Issue(s)

Closes none

Motivation

Today the workflow only bumps package.json and package-lock.json. manifest.json carries no version, so a deployed plugin cannot be traced back to a release, and the plugin changelogs have to be updated by hand, which is easy to forget and lets them drift from the tags. The manifest bump follows the same jq approach already used by other plugins built from this template.

More

Tested locally by running the workflow steps against a scratch clone of v0.1.x (with git push disabled):

• minor bump with a previous tag: manifest.json gains version, both changelogs get a new entry, and dpkg-parsechangelog parses the resulting debian/changelog;
• patch bump with no new commits and a hand-written CHANGELOG.md entry: CHANGELOG.md is kept as is, debian/changelog gets chore: release v0.2.1;
• no previous tag, no CHANGELOG.md and no debian/: only the version files change and the changelog steps are skipped.

Notes for reviewers:

• on the first release of a repository without tags, the changelog entry lists the whole history;
• the debian/changelog maintainer is copied from the previous entry rather than taken from the user who triggered the workflow.