Revises getting-started and index pages for MRs

What does this MR do?

This merge request fully tackles one known problem with the index page about merge requests (https://docs.gitlab.com/ee/user/project/merge_requests/) and lays groundwork for more work.

• It moves the "Assignee" one-liner from getting_started.md to index.md. I need to shuffle more things for #327432 but … MVC, Amy. MVC.
• It combines several filtering-related subheadings into one "filter merge requests" subheading. The introduced-in lines for each type of filtering are now in the "filter merge requests" subheading, and the different types of filtering are described MUCH more succinctly.
• Deletes two images we no longer need.

Questions for my trusty reviewer:

• I tried to come up with an aggregate name for the user-related filters. If you have a better idea, I wanna know. The attentive eye will notice a double colon on line 81 so I might as well acknowledge it now
• Did I describe the difference between Approver and Approved-by in a comprehensible way?

Related issues

• Related to Docs: Clarify merge request Assignee vs Reviewe... (#327432) - more work is needed here, but I can start chopping a little information out. I'm hesitant to do more because I have a feeling crosslinks may be a problem.
• Closes Merge requests docs don't mention sorting options (#335679 - closed) because it completely handles the description of sorting

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding or changing the main heading of the page (H1), ensure that the product tier badge is added.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.