Improve branch selection logic for docs:check Hugo build job

What does this MR do?

Two fixes for the docs-lint hugo CI job. This job needs to checkout a copy of the Docs website that matches the version of the MR or branch that a change to Omnibus is targeting, and it was missing handling for two scenarios:

1. If Chart cuts a release branch and then needs to merge a docs change to it before the Docs site's corresponding release branch exists, we need to fallback to the Docs site's main branch for the Hugo build job. If we attempt to checkout a non-existent docs site branch, the job incorrectly fails.

   This can happen shortly before a release since the Docs site release branch is cut on release day, but other projects cut their branches earlier.

   Same fix in gitlab: gitlab!204420 (merged)

2. Branch selection logic was also wrong for commits that run outside of MRs, like a direct push to a branch with a security fix, which happened here. This was because the original code only checked against CI_MERGE_REQUEST_TARGET_BRANCH_NAME, which is only available in merge request pipelines. When the job ran for other pipeline types (like PROTECTED_TEST_PIPELINE in that case), this variable was empty, so the branch detection logic failed and it always defaulted to the (incorrect) main docs branch.

   Similar fix in gitlab: gitlab!200118 (merged)

Why was this MR needed?

Avoids invalid pipeline failures that can potentially block non-standard merges (like backports).

What's the best way to test this MR?

I tested behavior for 18-2-stable as an example by adjusting this MR to target it:

MR target branch	Expected Docs branch	Example
18-2-stable	18.2	https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/11584396819
main	main	https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/11584112352

What are the relevant issue numbers?

gitlab-org/technical-writing/docs-gitlab-com#450 (closed)