Refactor of appearance/customization docs

What does this MR do?

The documentation concerning customization of the appearance of self-hosted GitLab instances is out of date, and not located properly within the docs.

This moves almost everything from /customization to /user/admin_area, and combines them all into one simple page, along with updated screenshots and descriptions, and any missing information.

Only one of the redirected docs had comments, so they are being redirected via the disqus_identifier frontmatter.

More details

Old	New
customization/branded_login_page.md	Moved to /user/admin_area/appearance.md#sign-in--sign-up-pages
customization/branded_page_and_email_header.md	Moved to /user/admin_area/appearance.md#navigation-bar
customization/favicon.md	Moved to /user/admin_area/appearance.md#favicon
customization/help_message.md	Moved to /user/admin_area/settings/help_page.md (special case)
customization/index.md	Moved to /user/admin_area/appearance.md
customization/libravatar.md	Moved to /administration/libravatar.md (special case)
customization/new_project_page.md	Moved to /user/admin_area/appearance.md#new-project-pages
customization/system_header_and_footer_messages.md	Moved to /user/admin_area/appearance.md#system-header-and-footer-messages

Special Cases:

• Libravatar is not an admin_area setting, but was listed in customization. I moved it to /administration, but left the content 100% untouched.
• customization/help_message.md is not an admin_area appearance setting. It is in admin_area/settings/preferences, so I moved it to /user/admin_area/settings/help_page.md, and updated it as well since it was completely missing an option, and the screenshots were woefully out of date.

Related issues

Resolves #31189 (closed)

Author's checklist

• Follow the Documentation Guidelines and Style Guide.
• If applicable, update the permissions table.
• Link docs to and from the higher-level index page, plus other related docs where helpful.
• Apply the documentation label.

Review checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.

1. Primary Reviewer

• Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

2. Technical Writer

• Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.

3. Maintainer

1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
2. Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist.
3. If there has not been a technical writer review, create an issue for one using the Doc Review template.