New workflow for creating release branches

[DanRod1999]

New workflow only for creating release branches off of already existing release branches. This is intended only to use when master is on a different minor branch then the one we are currently using. This will be needed for new 4.x minors while 5.0 is currently in development.

Related issue: https://github.com/iTwin/itwinjs-backlog/issues/1316

The purpose of a new workflow is to avoid changing the logic of the currently existing bump version pipeline. I believe re working the current scripts (here and in native) would be more difficult and would risk breaking what already works.

I will admit there are already a few parts of the current scripts I don't like, so maybe it would be worth while to rework in the future (I have an issue already created for it). So if anyone does work on that script, it might be better to address everything in one large change instead of multiple (most likely still large) changes.

[DanRod1999]

This commit on branch TEST/0.0x is an example of what we would see when running this off of a release branch. Branch TEST/0.0.x was auto created by this pipeline, so that value represents what will be a normal release branch ex. release/4.12.x.
Here is the workflow run that performed this.

Slight differences from my test and what would actually take place:

• This was triggered by my PR. Normally this should be triggered manually, but GH does not seem to allow manual triggers for workflows that do not exist on master. Because of this i had to make the workflow run using a PR trigger which strangely works
• I hard coded values for the branch name TEST/0.0.x as an env var. This should really be an input var set under workflow_dispatch. This is very similar to parameters that we set on run time for ADO.
• this was ran off of a branch based on master. So this commit might look a little different compared to when running off of a release branch. However, I believe it should look mostly the same, and the logic still all holds true.