Enable publishing updates to non-latest major.minor tags for GitHub action

As identified in #223, there is currently a gap in the automated releases for this repo.

Versioning for the GitHub action uses tags in the repo. When someone references `devcontainers/ci@vX.Y` the workflow runner will look for the `vX.Y` tag in the repo to fetch.
For the Azure DevOps task, the code is packaged as a VSIX file and submitted to the store. The version of the extension matches the version used in the GitHub release tag. In addition to the extension version, tasks within an extension have their own versions (and there can be multiple versions of a task in sepearate folders in the extension - see [here](https://learn.microsoft.com/en-us/azure/devops/extend/develop/integrate-build-task?view=azure-devops#bundle-multiple-versions-of-buildrelease-tasks-within-one-extension)).

So, for Azure DevOps tasks a breaking change can be handled by creating a new task version in a folder alongside the existing task. We can publish updates to either task version in a new extension published from main.

The capability that we want to enable is releasing versions of the GitHub action prior to the latest `major.minor` version (e.g. new versions of `v0.2`)

The current versioning process:
- read version from AzDO json file (** which one?)
- set outputs based on the major + minor from json file, and patch from build number
- set patch from output for AzDO
- set tags from outputs for GH

Proposed versioning process:
- new JSON file with major/minor values. Allows for different values per-branch
- read JSON file to set outputs
- rename ci_main to ci_release
- Add params to ci_common to control whether to publish GH and whether to publish AzDO
- ci_release (prev. ci_main) sets publish GH to true, and publish AzDO to true when on release/XXX
- ci_branch sets publish to false for both GH & AzDO
- Update triggers for ci_release to include release/XXX branches

Start by tracing the current ci_main, ci_common, and ci_branch workflows and identify which Azure DevOps JSON file supplies the version. Compare their existing version, tag, and release triggers with the proposed ci_release flow and the release/XXX branches. Done means non-latest major.minor GitHub action tags can be updated without disrupting Azure DevOps task publishing.

Written by the indexing model from the issue text.