Pin default datadog-ci and add local bump/release scripts

[juan-fernandez]

Summary

• Pin the default datadog-ci-version to v5.14.0 instead of the floating v5 selector.
• Add scripts/bump-datadog-ci-version.sh so action.yaml and README.md stay in sync when the default datadog-ci version changes.
• Add a local gh-based maintainer flow:
  • scripts/create-datadog-ci-bump-pr.sh checks for a newer DataDog/datadog-ci release and opens a labeled bump PR.
  • scripts/release-datadog-ci-bump.sh creates the next immutable action release tag, updates the moving major tag, and creates the GitHub Release.
• Document the release process in RELEASE.md and link to it from the README.
• Extend CI coverage for the pinned default and the local helper scripts.

Situation today

Users without a datadog-ci-version input install v5, which means:

• 👍 they get transparent updates, including security updates
• 👎 any compromised update also gets through

Users with a datadog-ci-version input:

• 👎 they do not get transparent updates
• 👍 no compromised updates get through

Proposed model

This PR pins the default value of datadog-ci-version and adds a maintainer flow to track updates to that default, so there can be a junit-upload-github-action release for each datadog-ci release.

The main advantage is that it is becoming more common to pin actions to a specific SHA or version, and automations like Dependabot already know how to update those references. The same end result is possible today by updating the datadog-ci-version input directly, but that is action-specific configuration and generic update tooling will usually miss it.

Situation after this change

Users without a datadog-ci-version input install whatever version is the default for that version of junit-upload-github-action, which means:

• :neutral: they do not get transparent updates, but Dependabot and similar tools can pick up updates to junit-upload-github-action automatically
• 👍 no compromised update gets through, because updating datadog-ci is gated by an explicit action update

Users with a datadog-ci-version input:

• 👎 they do not get transparent updates
• 👍 no compromised updates get through

Maintainer flow

1. Run scripts/create-datadog-ci-bump-pr.sh locally from a clean working tree.
2. Review and merge the resulting PR with the datadog-ci-version-bump label.
3. Run scripts/release-datadog-ci-bump.sh locally to publish the action release.

Release behavior:

• By default, the release script publishes the latest unreleased merged bump PR.
• If older unreleased bump PRs also exist, the script warns and still releases only the latest one.
• To release an older merge commit intentionally, run the script with --pr <number> or --sha <commit> before releasing the latest one.
• A release creates the next immutable action tag, updates the moving major tag, and creates a GitHub Release.

[BridgeAR]

The change is LGTM. This has the benefit of preventing the http request necessary at the moment.
Could we add a test for the default behavior as well?

[BridgeAR]

Suggested change

	By default, this action installs the exact `datadog-ci` release pinned by the action version you use. To receive `datadog-ci` updates, update `datadog/junit-upload-github-action` to a newer release.
	By default, this action installs the exact `datadog-ci` release pinned by the action version you use. To receive `datadog-ci` updates, update `datadog/junit-upload-github-action` to a newer release or use
	the `datadog-ci-version` configuration to specify the version or range.