[wiki migration] Leftover wiki pages and links (#148989)

This is waiting on 
- https://github.com/flutter/flutter/pull/148777
- https://github.com/flutter/flutter/pull/148790

After this PR lands, there will likely be 1-2 more clean up PRs, after which the migration will be done!

---

This moves the remaining wiki pages as planned in [flutter.dev/go/migrate-flutter-wiki-spreadsheet](https://docs.google.com/spreadsheets/d/1x65189ZBdNiLRygpUYoU08pwvXD4M-Z157c6pm8deGI/edit?usp=sharing) 

It also adds the team labels to the label bot for future PRs.

Changes to the content were only updating cross links, or links to refer to the main branch rather than master.
Remaining links to the wiki will be updated once all other pages have finished moving, they still work in the meantime.

Part of https://github.com/flutter/flutter/issues/145009

docs/about/Glossary.md

@@ -26,7 +26,7 @@ Here are some terms that we use in the Flutter project and what they mean:
 
 - **Modular application delivery**. The ability to package a single app into multiple separate archives when compiling it, and download them independently as needed.
 
-- **NTE**. "Needs-Tests Exemption". Indicates that a PR does not need tests, typically because the PR is refactoring code without changing the semantics of the code, or because it actually does have tests but the automated systems didn't recognize them. A test exemption consists of a comment on the PR that has a line that starts with the string `test-exempt: ` followed by an explanation of why, from someone who is allowed to give test exemptions. A bot will add a comment to a PR if a test exemption is required. See [Tree Hygiene](https://github.com/flutter/flutter/wiki/Tree-hygiene) for instructions on getting test exemptions.
+- **NTE**. "Needs-Tests Exemption". Indicates that a PR does not need tests, typically because the PR is refactoring code without changing the semantics of the code, or because it actually does have tests but the automated systems didn't recognize them. A test exemption consists of a comment on the PR that has a line that starts with the string `test-exempt: ` followed by an explanation of why, from someone who is allowed to give test exemptions. A bot will add a comment to a PR if a test exemption is required. See [Tree Hygiene](../contributing/Tree-hygiene.md) for instructions on getting test exemptions.
 
 - **Out-of-band (OOB) failure**. A test failure in our CI that is caused by some change external to the repository, not the failing commit (or flake). For instance, an infrastructure change or a change to an external server used by tests could cause an out-of-band failure. In general, CI should minimize the possibility of out-of-band failures by being as hermetic as possible.
 

docs/about/Project-teams.md

@@ -30,14 +30,14 @@ The Flutter project has many teams, including, but not limited to:
 
 There are also specific cross-cutting areas of work that may have their own subteam and that affect multiple subteams (e.g. accessibility, performance, etc).
 
-We also work closely with other projects, such as [Dart](https://dart.dev) and [Skia](https://skia.org), and with many [customers](https://github.com/flutter/flutter/wiki/Issue-hygiene#customers).
+We also work closely with other projects, such as [Dart](https://dart.dev) and [Skia](https://skia.org), and with many [customers](../contributing/issue_hygiene/README.md#customers).
 
 ## Responsibilities
 
 Subteams are responsible for reviewing PRs in their area, triaging issues, and scheduling work.
 How subteams organize themselves is not defined by this document. This document does not attempt to impose a process, merely a set of responsibilities.
 
-See the [Roadmap](https://github.com/flutter/flutter/wiki/Roadmap) and [What should I work on?](https://github.com/flutter/flutter/wiki/What-should-I-work-on%3F) pages for details on how to prioritize work.
+See the [Roadmap](../roadmap/Roadmap.md) and [What should I work on?](../contributing/What-should-I-work-on.md) pages for details on how to prioritize work.
 
 ### Reviewing PRs
 
@@ -47,7 +47,7 @@ Please review PRs in your area (based on label and/or repositories). The goal is
 
 Please triage issues with your label on a regular basis. You may do this in whatever manner you prefer (on your phone while in line for lunch, as a team exercise in a dedicated meeting room, by having some sort of team rotation, whatever).
 
-You must cover these bug lists in particular: https://github.com/flutter/flutter/wiki/Triage#area-focused-triage
+[You must cover these bug lists in particular.](../triage/README.md#triage-process-for-teams)
 
 * Assign bugs that you are working on or that you have committed to work on.
 
@@ -55,9 +55,9 @@ You must cover these bug lists in particular: https://github.com/flutter/flutter
 
 * Make sure that assigned bugs have a month-based milestone (see section below).
 
-See our page on managing issues: https://github.com/flutter/flutter/wiki/Issue-hygiene
+[See our page on managing issues.](../contributing/issue_hygiene/README.md)
 
-Keep an eye out for bugs that should block releases, update the bad builds page accordingly: https://github.com/flutter/flutter/wiki/Bad-Builds
+Keep an eye out for bugs that should block releases, update the [bad builds](../releases/Bad-Builds.md) page accordingly.
 
 ### Be conservative when scheduling
 

docs/about/Values.md

@@ -45,7 +45,7 @@ We may sometimes gate features behind flags until we are confident of their qual
 
 ## 🤣‬ Have fun doing it
 
-Last, but definitely not least, we want to make sure that our work environment is pleasant for everyone involved. Your health and the health of your family and friends is more important than Flutter. Our community [is welcoming](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md). We don't know everything; all of us can make mistakes.
+Last, but definitely not least, we want to make sure that our work environment is pleasant for everyone involved. Your health and the health of your family and friends is more important than Flutter. Our community [is welcoming](../../CODE_OF_CONDUCT.md). We don't know everything; all of us can make mistakes.
 
 We want team members to feel empowered to make changes to the code and to our processes.
 
@@ -70,7 +70,7 @@ The list of supported platforms on flutter.dev is describing the platforms suppo
 
 For each area, we consider the level to which we provide support:
 
-0. We will literally help you with your code if things don't work. This is very rare. (See also "[top-tier customers](https://github.com/flutter/flutter/wiki/Issue-hygiene#customers)".)
+0. We will literally help you with your code if things don't work. This is very rare. (See also "[top-tier customers](../contributing/issue_hygiene/README.md#customers)".)
 
 1. We will make a best effort to ensure that well written code works (e.g. we have testing on that platform). This is a common level for target platforms that have reached a label of "stable" (e.g. Android, iOS) on devices that are widely available (e.g. 64bit ARM). This corresponds to the "Supported Google-tested platforms" category on the list of supported platforms.
 
@@ -89,7 +89,7 @@ For each area, we consider the level to which we provide support:
 
 _See also:_
 
-* [Code of Conduct](https://github.com/flutter/flutter/blob/main/CODE_OF_CONDUCT.md)
-* [Contributor Guide](https://github.com/flutter/flutter/blob/main/CONTRIBUTING.md)
+* [Code of Conduct](../../CODE_OF_CONDUCT.md)
+* [Contributor Guide](../../CONTRIBUTING.md)
 * [Flutter's Culture of Inclusivity](https://flutter.dev/culture)
 * [Flutter culture and how to preserve it](https://medium.com/flutter/flutter-culture-and-how-to-preserve-it-436b4ed1031d)