Resolve "Fix HTML validation issues on templates"

What does this MR do and why?

Describe why, not just what. Include links to relevant issues or discussions.

This MR addresses the issues regarding accessibility on new docs site (refer to screenshots for the list):

1. First set of issues on https://validator.w3.org/nu/?doc=https%3A%2F%2Fnew.docs.gitlab.com%2F

   1. For point 1 and point 2, when loading links, in this case GitLab fonts, we are using "as=font" keywords, which requires either "preload" or "modulepreload" for "rel" attribute (relationship attribute).
      1. We do not want to use "modulepreload" because it is specifically for javascript modules and fonts are not considered as javascript modules (https://web.dev/articles/modulepreload).
      2. Solution:
         1. we can keep using prefetch -> but we need to remove "as=font" because it is not supported on all browsers and it's optional for prefetch. Prefetch allows for better performance as it loads the fonts as soon as user visits the website avoiding font loading delays later.
   2. Point 3, stray </div> tag was found in head.html.
   3. Point 4, when using aria-label we must have a role for that element as well. There are specific roles that MDN specifies.
   4. When using <section> tags, we need to have at least one header element (https://www.shecodes.io/athena/11438-difference-between-div-section-in-html). In the case mentioned in point 5 (above screenshot), this section is simply a footer where no headers are rendered, therefore it can be just a normal div.
   5. For point 6, when using aria-labelledby in the parent, there must be a child element that has a matching id for the same string.

2. First set of issues on https://validator.w3.org/nu/?doc=https%3A%2F%2Fnew.docs.gitlab.com%2Fdevelopment%2Fdocumentation%2Fstyleguide%2F:

   1. Points 1-4 are addressed in the above points.
   2. Point 5 -> iframe's attribute "frameborder" is no longer available. We can override this by adding css using border: 0 to achieve the same effect.
   3. Point 6 -> we cannot use block elements <h2> within buttons. So I have changed it to use an inline element <span> and added h2 styling.
   4. Point 7 -> we cannot use block elements like <div> within buttons. We can only use inline elements like <span>
   5. Points 8 and 9 -> We cannot use special characters in href strings like "[" or "]"

      1. example ([description], or [title] ):

         <p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue[description]=Describe%20what%20you%20would%20like%20to%20see%20improved.%0A%0A%3C!--%20Don%27t%20edit%20below%20this%20line%20--%3E%0A%0A%2Flabel%20~%22docs%5C-comments%22%20&issue[title]=Docs%20-%20product%20feedback:%20Write%20your%20title">Create an issue</a> if there's something you don't like about this feature.</p>

         <p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal%20-%20detailed&issue[title]=Docs%20feedback%20-%20feature%20proposal:%20Write%20your%20title">Propose functionality</a> by submitting a feature request.</p>

      2. Instead we have encode those special characters using special codes for example "[" => "%5B".

         1. So with change -> <p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue%5Bdescription%5D=Describe%20what%20you%20would%20like%20to%20see%20improved.%0A%0A%3C!--%20Don%27t%20edit%20below%20this%20line%20--%3E%0A%0A%2Flabel%20~%22docs%5C-comments%22%20&issue%5Btitle%5D=Docs%20-%20product%20feedback:%20Write%20your%20title">Create an issue</a> if there's something you don't like about this feature.</p>

Screenshots, screen recordings, or links to review app

These are strongly recommended to assist reviewers and reduce the time to merge your change.

These were the previous issues regarding accessibility:

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Configure a local GitLab Docs environment: https://gitlab.com/gitlab-org/technical-writing-group/gitlab-docs-hugo/-/blob/main/doc/setup.md.

Merge request acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this merge request.

Closes #121 (closed)