Change "Performance and Testing" to "Availability and Testing" in MR templates and add "How should this be manually tested?" section

Background

After doing some code reviews that are not under my team's domain, whenever I want to test the changes in an MR and I'm not familiar with the feature being changed or the related feature going to be affected/fixed, it takes time as I need to find it if it's not obvious.

As a reviewer, I can ask the author but that will be another back-and-forth between the two of us. That will also take time especially if there's a huge TZ diff between the reviewer and author.

Proposal

Add an optional How can this be manually verified? section to the merge request default description. This way, the reviewer can easily see what steps can be taken to test a feature or a bug fix. This is not only helpful for the reviewer but I believe it will also be helpful for other users (e.g. PM, UX) that wants to test the changes.

This new section can be added after the Availability and Testing section. It will look like:

## What does this MR do?

<!--

Describe in detail what your merge request does and why.

Are there any risks involved with the proposed change? What additional
test coverage is introduced to offset the risk?

Please keep this description up-to-date with any discussion that takes
place so that reviewers can understand your intent. This is especially
important if they didn't participate in the discussion.

-->

## Screenshots

<!-- Please include any relevant screenshots that will assist reviewers and future readers -->

## Does this MR meet the acceptance criteria?

### Conformity

- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) 
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html) or [follow-up review issue created](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review)
- [ ] [Code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] [Merge request performance guidelines](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] [Style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/development/contributing/style_guides.md)
- [ ] [Database guides](https://docs.gitlab.com/ee/development/README.html#database-guides)
- [ ] [Separation of EE specific content](https://docs.gitlab.com/ee/development/ee_features.html#separation-of-ee-code)

### Availability and Testing

<!-- What risks does this change pose? How might it affect the quality/performance of the product?
What additional test coverage or changes to tests will be needed?
Will it require cross-browser testing?
See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->

<!-- If cross-browser testing is not required, please remove the relevant item, or mark it as not needed: [-] -->

- [ ] [Review and add/update tests for this feature/bug](https://docs.gitlab.com/ee/development/testing_guide/index.html). Consider [all test levels](https://docs.gitlab.com/ee/development/testing_guide/testing_levels.html). See the [Test Planning Process](https://about.gitlab.com/handbook/engineering/quality/test-engineering).
- [ ] [Tested in all supported browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)

#### How can this be manually verified?

<!-- 
This section is optional.

Add the necessary steps to verify the changes in this merge request
including the expected outcome.

Example:

1. Click the "New merge request" button.
2. Set the title, description and set yourself as "Assignee".
3. Submit the form.

A merge request should be created and should be assigned to you.
-->

> Note: The steps listed are provided for those unfamiliar with the change.
They are the minimum required to verify that the change is in place,
but they should not substitute for good automated test coverage and more
thorough testing during development.

Author's checklist:

- [ ] Add the necessary steps to verify the changes in this merge request
including the expected outcome.

Reviewer's checklist:

- [ ] Verify the change and post artifacts such as screenshots/gifs
of what has been manually tested.


### 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](https://about.gitlab.com/handbook/engineering/security/#when-to-request-a-security-review):

- [ ] Label as ~security and @ mention `@gitlab-com/gl-security/appsec`
- [ ] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [ ] Security reports checked/validated by a reviewer from the AppSec team