Revise forking page in prep for new feature

What does this MR do?

In prep for making forking easier through the UI, I read through https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html and realized this page could use some polish. Lots of gerunds, and the "Removing a fork relationship" section pointed to instructions in the "Advanced Settings" page: https://docs.gitlab.com/ee/user/project/settings/index.html#remove-a-fork-relationship

This merge request applies a light coat of polish to the entire page, but should not be construed as a full CTRT edit:

• Better wording
• Subheadings with gerunds shifted to present tense
• Unlink-a-fork info moved from doc/user/project/settings/index.md
• While I was on that page, I noticed a troubleshooting item about forking, so I moved it too
• Tidied the related info about object pools + forks at doc/development/git_object_deduplication.md and, by the end of it, understood it wasn't where we should link the user to, anyway. Substantial rewriting in the forking page to simplify the explanation of what happens to object pools when a fork is unlinked
• Updated all the crosslinks I could find
• Updates the two links in the app I could find. One of them seems odd, so I'll be seeking a second opinion on whether or not we're linking to the right place.

Related issues

Related to Fetch new upstream contents when fork is behind (#330243 - closed) - this merge request gets the landing page ready for this new feature.

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.