[feature/fix] Excluding backported fixes from feature release change logs

[nemesifier]

Follow up of #496.

We should do this once #496 is completed.

Two ways that we can both use to avoid duplicating backported bugfixes in the change log of new feature releases.

Step 1: automatically determine from current stable branch.

• Detect whether we are on the main branch (master/main), if we are not, stop, else continue
• Now we need to find out what's the latest stable version branch, I think a reliable way to do this would be to look at tags/releases (whatever is easier, if we use tags, we'll need to run git pull --tags first), look for the latest feature release, eg: 1.1.0, so we know the current stable branch is 1.1
• If the branch does not exist, stop, else continue
• Get the git log for the stable branch from the latest stable release onwards
• Most commits contain the original commit hash from which they were cherry picked from in the main branch, eg: 6eadd4e, see (cherry picked from commit 5a32721), if this line is missing, stop, else continue
• Fetch all the "cherry picked from commit" hashes and compile a temporary ignore file for gitcliff

Step 2: [backport] tag mentioned (related to #501)

• Loop over all the commits that are going to be included in the change log, if the commit message contains [backport], skip them or add them to the gitcliff ignore file (whatever makes the code easier to maintain/read).

Using both methods is redundant by design to catch most cases, including when we may forget to use the [backport] tag and perform the backport manually with git cherry-pick -x.

Step 3: cleanup

The ignore file for git-cliff should be generated on the fly, used during release process, and then discarded.