chore: add infrastructure to patch latest version

[nedsalk]

This PR adds infrastructure to patch the last release. Given that this workflow releases commits that are not on master, we'll have to manually apply those commits' changes to master if the released code doesn't already exist on it.

Besides the release of the package itself, the documentation also gets updated when this scenario occurs.

closes #2245

[arboleya]

Should we document the process as we did for patching old releases?

fuels-ts/CONTRIBUTING.md

Lines 240 to 248 in 269197f

	# Patching old releases
	The following example is for releasing a patch for `v0.69.0` -> `v0.69.1`.
	- Checkout the release commit via its tag and create a release branch based on it (`git checkout -b release/0.69.0 v0.69.0 && git push --set-upstream origin release/0.69.0`)
	- Create PRs with base set to that release branch
	- When the PR is merged, a changeset PR is created
	- When the changeset PR is merged into the release branch, the next patch version is released and the commit is tagged (e.g. `v0.69.1`)
	- After release, delete the release branch from GitHub

[petertonysmith94]

Out of curiosity, how do we test these type of release workflows?

[nedsalk]

@petertonysmith94 The actual full workflow would be tested in the trenches after we merge it into master and release a new version of master. We'd then run this workflow on that release/v0.xx.x branch by doing a simple, non-breaking change and verifying that everything works as expected. 😅
However, I tested all the added logic in the CI in isolation, e.g. #2529 for PR creation and running the bash scripts in the CI on mock data to verify that there's no failure in them.

[petertonysmith94]

@nedsalk thanks for explaining, super valuable insight - got to love some trenches testing 😆

It looks good me 🚀

[github-actions]

Coverage Report:

Lines	Branches	Functions	Statements
80.96%(+0%)	72.55%(+0%)	77.98%(+0%)	81.01%(+0%)

Changed Files:

Coverage values did not change👌.

[arboleya]

Firstly, thanks for addressing this final piece on our release process.

Having said that, I couldn't properly validate it. I mean no offense, but the changes in this PR are too convoluted and unreadable (hard to follow). If we add the fact that it is purely text (CI/YAML), the job becomes even more challenging. It is like validating code on a piece of paper.

I know others have approved it, but I wonder if they could accurately explain it back to you.

I'll go ahead and approve it as is so you can validate it yourself in practical terms. I suggest doing that in isolation at the beginning of your day so you can see it through and make any extra fixes on the spot if necessary.

[nedsalk]

@arboleya you're right that these scripts aren't the most readable code. I have created #2581 where we can evolve the discussion and hopefully come to a better CI workflow codebase.