Reintroduce RC builds for releases branches

[gr0vity-dev]

This PR improves the next_tag_generation that was introduced in #PR4256 and replaces what we had before

Here are a few examples of what tag is generated when running the workflow :

develop branch (uses 'DB' as suffix)

|---------|--------------|------------------|-------------------------------------|
| attempt |  branch_name | is_release_build |  result                             |
|---------|--------------|------------------|-------------------------------------|
|       1 |   develop    |  ignored         |  create tag V27.0DB1                | (no V27.0DB* tag exists, so it's created)
|---------|--------------|------------------|-------------------------------------|
|       2 |   develop    |  ignored         |  no new commit --> exit 0           |
|---------|--------------|------------------|-------------------------------------|
|       3 |   develop    |  ignored         |  new commit --> create tag V27.0DB2 |
|---------|--------------|------------------|-------------------------------------|

releases/v branch (uses 'RC' as suffix)

-if IS_RELEASE_BUILD is set to true during workflow execution, the suffix is ignored

|---------|----------------|------------------|----------------------------------------|
| attempt |  branch_name   | is_release_build |  result                                |
|---------|----------------|------------------|----------------------------------------|
|       1 |   releases/v26 |  false (default) |  create tag V26.0RC1                   | (no V26.0RC* tag exists, so it's created)
|---------|----------------|------------------|----------------------------------------|
|       2 |   releases/v26 |  false           |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       3 |   releases/v26 |  false           |  new commit --> create tag V26.0RC2    |
|---------|----------------|------------------|----------------------------------------|
|       4 |   releases/v26 |  true            |  create tag V26.0                      |
|---------|----------------|------------------|----------------------------------------|
|       5 |   releases/v26 |  true            |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       6 |   releases/v26 |  false           |  no new commit --> create tag V26.1RC1 | (no V26.1RC* tag exists, so it's created)
|---------|----------------|------------------|----------------------------------------|
|       7 |   releases/v26 |  false           |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       8 |   releases/v26 |  true            |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       9 |   releases/v26 |  false           |  new commit --> create tag V26.1RC2    |
|---------|----------------|------------------|----------------------------------------|
|      10 |   releases/v26 |  true            |  new commit --> create tag V26.1       | (commit `set(CPACK_PACKAGE_VERSION_MINOR "1")` to releases/v26)
|---------|----------------|------------------|----------------------------------------|

When looking at attempt 6, the minor_version is set to 1 because a V26.0 release build exists (created in attempt 4).

Any other branch uses the branch_name as suffix

|---------|------------------|------------------|----------------------------------------------------|
| attempt |  branch_name     | is_release_build |  result                                            |
|---------|------------------|------------------|----------------------------------------------------|
|       1 |   prs/good_stuff |  ignored         |  create tag V{Maj}.0prs_good_stuff1                |
|---------|------------------|------------------|----------------------------------------------------|
|       2 |   prs/good_stuff |  ignored         |  no new commit --> exit 0                          |
|---------|------------------|------------------|----------------------------------------------------|
|       3 |   prs/good_stuff |  ignored         |  new commit --> create tag V{Maj}.0prs_good_stuff2 |
|---------|------------------|------------------|----------------------------------------------------|

[pwojcikdev]

Based on flowchart this makes a lot of sense, but I haven't gone through the bash scripts in much detail. We can always fix problems later.

Would it be a good idea to rename .github/workflows/artifacts_build_deploy.yml to simply .github/workflows/build_deploy.yml so it's shorter and matches actual workflow name?