Merge CONTRIBUTING.md into website contributing guide. (iree-org#15449)

Following up on some ideas noted at
iree-org#15116 (comment).

We had previously split "contributing" docs between the root
`CONTRIBUTING.md` and a separate developer doc. Now that the developer
doc is published on our website at
https://iree.dev/developers/general/contributing/, we can move more of
the documentation there and just have the root file point at the
website.

Preview for review:
https://scotttodd.github.io/iree/developers/general/contributing/

* I rewrote and reordered most of the sections
* I have more ideas for how to streamline these docs... trying to not
spent too much time on this right now though 😛
* Separate "infrastructure" page explaining how to interact with the CI
(build/test/benchmark/etc.)
* Deemphasize "contributor tips" and/or add more tips (like how to set
up Visual Studio Code)

I took some inspiration from https://llvm.org/docs/Contributing.html and
https://llvm.org/docs/DeveloperPolicy.html.

CONTRIBUTING.md

@@ -1,77 +1,20 @@
-# How to Contribute
+# How to contribute
 
-We'd love to accept your patches and contributions to this project. There are
-just a few small guidelines you need to follow.
+We'd love to accept your patches and contributions to this project.
 
-## Contributor License Agreement
+To get started with contributing, please take a look at the
+[Contributing](https://iree.dev/developers/general/contributing/) guide.
 
-Contributions to this project must be accompanied by a Contributor License
-Agreement. You (or your employer) retain the copyright to your contribution;
-this simply gives us permission to use and redistribute your contributions as
-part of the project. Head over to <https://cla.developers.google.com/> to see
-your current agreements on file or to sign a new one.
+## Getting in touch
 
-You generally only need to submit a CLA once, so if you've already submitted one
-(even if it was for a different project), you probably don't need to do it
-again.
+*   [GitHub issues](https://github.com/openxla/iree/issues): Feature requests,
+    bugs, and other work tracking
+*   [IREE Discord server](https://discord.gg/26P4xW4): Daily development
+    discussions with the core team and collaborators
+*   [iree-discuss email list](https://groups.google.com/forum/#!forum/iree-discuss):
+    Announcements, general and low-priority discussion
 
-## Changes Accepted
+## Community guidelines
 
-Please file issues before doing substantial work; this will ensure that others
-don't duplicate the work and that there's a chance to discuss any design issues.
-
-Changes only tweaking style are unlikely to be accepted unless they are applied
-consistently across the project. Most of the code style is derived from the
-[Google Style Guides](http://google.github.io/styleguide/) for the appropriate
-language and is generally not something we accept changes on (as clang-format
-and other linters set that for us). The compiler portion of the project follows
-[MLIR style](https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide).
-Improvements to code structure and clarity are welcome but please file issues to
-track such work first.
-
-## AUTHORS file
-
-If you would like to receive additional recognition for your contribution, you
-may add yourself (or your organization) to the AUTHORS file. This keeps track of
-those who have made significant contributions to the project. Please add the
-entity who owns the copyright for your contribution. The source control history
-remains the most accurate source for individual contributions.
-
-## Code reviews
-
-All submissions, including submissions by maintainers, require review. We
-use GitHub pull requests (PRs) for this purpose. Consult
-[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
-information on using pull requests.
-
-## Presubmits
-
-Most of our presubmit workflows will only run automatically on PRs if you are a
-project collaborator. Otherwise a maintainer must
-[approve workflow runs](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks).
-If you are sending code changes to the project, please ask to be added as a
-collaborator, so that these can run automatically. It is generally expected that
-PRs will only be merged when all checks are passing. In some cases, pre-existing
-failures may be ignored by a maintainer or admin.
-
-## Merging
-
-After review and presubmit checks, PRs should be merged with a "squash and
-merge". The squashed commit summary should match the PR title and the commit
-description should match the PR body (this is the default behavior).
-Accordingly, please write these as you would a helpful commit message. Please
-also keep PRs small (focused on a single issue) to streamline review and ease
-later culprit-finding. It is assumed that the PR author will merge their change
-unless they ask someone else to merge it for them (e.g. because they don't have
-write access).
-
-## Details
-
-For further details, see our
-[detailed contributing guide](https://iree.dev/developers/contributing/), which is
-separate to avoid notifying everyone every time it changes.
-
-## Community Guidelines
-
-This project follows
-[Google's Open Source Community Guidelines](https://opensource.google.com/conduct/).
+This project follows the
+[OpenXLA Code of Conduct](https://github.com/openxla/community/blob/main/CODE-OF-CONDUCT.md).