Update readme to reflect ties to FAST project (#184)

# Pull Request

## 📖 Description

<!--- Provide some background and a description of your work. -->
This change cleans up the root level `CONTRIBUTING.md` file to point to FAST projects guidance as the two projects share a governing body.

## ✅ Checklist

### General

<!--- Review the list and put an x in the boxes that apply. -->

- [ ] I have added tests for my changes.
- [ ] I have tested my changes.
- [x] I have updated the project documentation to reflect my changes.

CONTRIBUTING.md

@@ -98,66 +98,9 @@ You can use any code editor you like when working with the FAST Tooling monorepo
 
 Default VS Code settings for this project are configured as [Workspace settings](https://code.visualstudio.com/docs/getstarted/settings) in the `.vscode` directory. These settings override user settings for the workspace and are configured to ensure consistent code formatting across different environments. We also include a list of [Workspace recommended extensions](https://code.visualstudio.com/docs/editor/extension-marketplace#_workspace-recommended-extensions) for VS Code for syntax highlighting and code linting.
 
-## Contribution policy
+## FAST guidance
 
-A “Contribution” is work voluntarily submitted to a project. This submitted work can include code, documentation, design, answering questions, or submitting and triaging issues.
-
-Many contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to grant and do grant the rights to use your contribution. For details, visit [https://cla.microsoft.com](https://cla.microsoft.com).
-
-When you submit a pull request, a CLA-bot automatically determines if you need to provide a CLA and decorates the pull request appropriately (e.g., label, comment). Follow the instructions provided by the bot. You only need to do this once across all repositories using our CLA.
-
-## Guiding principle
-
-Owners, the steering committee, collaborators, code owners, and contributors work in concert with one another on behalf of the FAST Tooling community and prioritize the communities interests over their own.
-
-The development, release, and work management processes must reflect this principle. Accepting contributions to the project requires a review by collaborators.
-
-## Governance
-
-### Owners
-
-*Owners* have admin access and are responsible for the management, maintenance, and operations of the FAST Tooling repository.
-
-### Steering committee
-
-*Steering committee* members are key *collaborators* who have demonstrated design or technical expertise critical to the driving the FAST Tooling project and community forward.
-
-### Collaborators
-
-*Collaborators* have write access and have an active and sustained impact on the project and participate in triaging issues, reviewing code, mentoring, and working to improve the architectural quality.
-
-### Code owners
-
-As subject matter experts, *code owners* approve pull requests on the packages they own. There is a required minimum of one code owner for each package. *Code owners* are listed in [CODEOWNERS](https://github.com/microsoft/fast-tooling/blob/main/.github/CODEOWNERS).
-
-### Contributors
-
-*Contributors* have read access and can be anyone who has contributed a completed pull request to the project.
-
-### Nominations & appointments
-
-* To become a *contributor*, a community member must have a pull request approved and merged into the FAST Tooling project main branch.
-* To become a *collaborator*, a *contributor* will petition the *steering committee* who will approve or deny the request.
-* To become a *code owner*, a *collaborator* will be (a) nominated by a *steering committee* member or (b) petition the *steering committee* who will approve or deny the request.
-* To join the *steering committee*, a *collaborator* will be nominated by a *steering committee* member and the *steering committee* who will approve or deny the request.
-
-## Acceptance and consensus seeking process
-
-Acceptance of contributions follows the consensus-seeking process.
-
-All pull requests must be approved by a *collaborator* before the pull request can be accepted.
-
-Before a pull request is accepted, time should be given to receive input from *collaborators* or *code owners* with the expertise to evaluate the changes. The amount of time can vary but at least 3 days during the typical working week and 5 days over weekends should be given to account for international time differences and work schedules.
-
-When a pull request : (a) has a significant impact on the project, (b) is inherently controversial, or (c) has not reached consensus with *collaborators*; add a "controversial" label to the pull request for the *steering committee* to review the pull request. Pull requests labeled with "controversial" are not approved until the *steering committee* reviews the issue and makes a decision.
-
-Additionally, *owners*, can temporarily enable [interaction limits](https://help.github.com/articles/limiting-interactions-with-your-repository/) to allow a "cool-down" period when hot topics become disruptive.
-
-Specific *collaborators* or *code owners*  can be added to a pull request by including their user alias.
-
-## Stability policy
-
-An essential consideration in every pull request is its impact on the system. To manage impacts, we work collectively to ensure that we do not introduce unnecessary breaking changes, performance or functional regressions, or negative impacts on usability for users or supported partners.
+The FAST Tooling project follows the contribution policy outlined in the FAST project for their [governance](https://github.com/microsoft/fast/blob/master/CONTRIBUTING.md#governance), [acceptance and consensus seeking process](https://github.com/microsoft/fast/blob/master/CONTRIBUTING.md#acceptance-and-consensus-seeking-process), and [stability policy](https://github.com/microsoft/fast/blob/master/CONTRIBUTING.md#stability-policy).
 
 ## Developer's Certificate of Origin 1.1