ci: Always enforce conventional commits

What does this MR do?

This makes sure all commits in an MR follow conventional commits standards.

After this MR is merged, GitLab UI's project settings will be changed to disallow squash and merge.

Why?

The main reason is to avoid accidentally not triggering a new release, which causes confusion (e.g., Why aren't my changes available yet? and Why aren't my changes listed in the changelog?) and wastes developer time. See #1562 (closed) for several historical examples of this, and additional details.

Alternatives

Some alternatives were proposed in this thread, but they all makes some room for human error, which is ultimately always the source of these "bad" merges. This MR guarantees *⃣ that there's no room human error.

What if this gets really annoying? I don't like doing git operations locally!

If this turns out to be too annoying, we can undo it, or change it 🙂 It's a two-way door decision.

Does this MR meet the acceptance criteria?

Conformity

• Code review guidelines.
• GitLab UI's contributing guidlines.
• [-] If it changes a Pajamas-compliant component's look & feel, the MR has been reviewed by a UX designer.
• [-] If it changes GitLab UI's documentation guidelines, the MR has been reviewed by a Technical Writer.
• [-] If the MR changes a component's API, integration MR(s) have been opened in the following projects to ensure that the @gitlab/ui package can be upgraded quickly after the changes are released:
  • [-] GitLab: mr_url
  • [-] CustomersDot: mr_url
  • [-] Status Page: mr_url
• [-] Added the ~"component:*" label(s) if applicable.

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

• [-] All actions and functionality can be done with a keyboard.
• [-] Links, buttons, and controls have a visible focus state.
• [-] All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
• [-] Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
• [-] Color combinations have sufficient contrast.

*⃣ Not guaranteed.