[docs] link new support policy from developer policy

[rengolin]

Summary

As requested in D90761, a small paragraph in the developer policy to
mention the different support levels.

Adding a new paragraph under "Adding an Existing Project" section to
check the different levels of support we have, to help introduction of
smaller set of changes without overwhelming new collaborators and
potentially losing the contribution.

[lattner]

Looks great, but I'd add this to the top of the "adding a new thing" section above the "new target" section. Could you also revise the 'new target' to be defined in the terms you established? I think it makes sense to retain the majority of the text there, but aligning on terminology would be good.

Thanks again!

[rengolin]

It's looking a bit redundant to me, but I wanted to make sure we have the link on all three sections in case people are given a link (or navigate from the table-of contents) and don't see the sections above.

This update adds:

• Links to the support policy
• Rewrite to accommodate existing style
• Specified the level of cover for each topic

[lattner]

I agree this is a bit redundant. I'd drop the two changes that I marked above in the diff, otherwise LGTM, thank you again!

llvm/docs/DeveloperPolicy.rst

702

I'd drop this mention.

726

and this mention

[GMNGeoffrey]

Thanks for adding this Renato :-) I was out the first part of this week, but LGTM

llvm/docs/DeveloperPolicy.rst

 ====================================
 
 The LLVM community is a vibrant and exciting place to be, and we look to be
 inclusive of new projects and foster new communities, and increase
 collaboration across industry and academia.
 
 That said, we need to strike a balance between being inclusive of new ideas and
 people and the cost of ongoing maintenance that new code requires.  As such, we
-have the following general policies for introducing major new components into
-the LLVM world.  However, this is really only intended to cover common cases
+have a general :doc:`support policy<SupportPolicy>` for introducing major new
+components into the LLVM world, depending on the degree of detail and
+responsibility required. *Core* projects need a higher degree of scrutiny
+than *peripheral* projects, and the latter may have additional differences.
+
+However, this is really only intended to cover common cases
 that we have seen arise: different situations are different, and we are open
 to discussing unusual cases as well - just start an RFC thread on the
 `llvm-dev mailing list`_.
 
 Adding a New Target
 -------------------
 
 LLVM is very receptive to new targets, even experimental ones, but a number of
 problems can appear when adding new large portions of code, and back-ends are
-normally added in bulk.  We have found that landing large pieces of new code
-and then trying to fix emergent problems in-tree is problematic for a variety
-of reasons.
-
-For these reasons, new targets are *always* added as *experimental* until
-they can be proven stable, and later moved to non-experimental. The differences
-between both classes are:
+normally added in bulk. New targets need the same level of support as other
+*core* parts of the compiler, so they are covered in the *core tier* of our
+:doc:`support policy<SupportPolicy>`.
+
+We have found that landing large pieces of new code and then trying to fix
+emergent problems in-tree is problematic for a variety of reasons. For these
+reasons, new targets are *always* added as *experimental* until they can be
+proven stable, and later moved to non-experimental.
+
+The differences between both classes are:
 
 * Experimental targets are not built by default (they need to be explicitly
   enabled at CMake time).
 
 * Test failures, bugs, and build breakages that only appear when the
   experimental target is enabled, caused by changes unrelated to the target, are
   the responsibility of the community behind the target to fix.
 

 
 The `LLVM monorepo <https://github.com/llvm/llvm-project>`_ is the centerpoint
 of development in the LLVM world, and has all of the primary LLVM components,
 including the LLVM optimizer and code generators, Clang, LLDB, etc.  `Monorepos
 in general <https://en.wikipedia.org/wiki/Monorepo>`_ are great because they
 allow atomic commits to the project, simplify CI, and make it easier for
 subcommunities to collaborate.
 
-That said, the burden to add things to the LLVM monorepo needs to be very high -
-code that is added to this repository is checked out by everyone in the
-community.  As such, we hold subprojects to a high bar similar to "official
-targets", they:
+Like new targets, most projects already in the monorepo are considered to be in
+the *core tier* of our :doc:`support policy<SupportPolicy>`. The burden to add
+things to the LLVM monorepo needs to be very high - code that is added to this
+repository is checked out by everyone in the community.  As such, we hold
+components to a high bar similar to "official targets", they:
 
  * Must be generally aligned with the mission of the LLVM project to advance
    compilers, languages, tools, runtimes, etc.
  * Must conform to all of the policies laid out in this developer policy
    document, including license, patent, coding standards, and code of conduct.
  * Must have an active community that maintains the code, including established
    code owners.
  * Should have reasonable documentation about how it works, including a high
    quality README file.
  * Should have CI to catch breakage within the project itself or due to
    underlying LLVM dependencies.
  * Should have code free of issues the community finds contentious, or be on a
    clear path to resolving them.
  * Must be proposed through the LLVM RFC process, and have its addition approved
    by the LLVM community - this ultimately mediates the resolution of the
    "should" concerns above.
 
 If you have a project that you think would make sense to add to the LLVM
 monorepo, please start an RFC thread on the `llvm-dev mailing list`_ to kick off
 the discussion.  This process can take some time and iteration - please don’t
 be discouraged or intimidated by that!
 
 If you have an earlier stage project that you think is aligned with LLVM, please
 see the "Incubating New Projects" section.
 
 Incubating New Projects
 -----------------------
 
 The burden to add a new project to the LLVM monorepo is intentionally very high,
 but that can have a chilling effect on new and innovative projects.  To help
 foster these sorts of projects, LLVM supports an "incubator" process that is
 much easier to get started with.  It provides space for potentially valuable,
 new top-level and sub-projects to reach a critical mass before they have enough
 code to prove their utility and grow a community.  This also allows
 collaboration between teams that already have permissions to make contributions
 to projects under the LLVM umbrella.
 
 Projects which can be considered for the LLVM incubator meet the following
 criteria:
 
  * Must be generally aligned with the mission of the LLVM project to advance
    compilers, languages, tools, runtimes, etc.
  * Must conform to the license, patent, and code of conduct policies laid out
    in this developer policy document.
  * Must have a documented charter and development plan, e.g. in the form of a
    README file, mission statement, and/or manifesto.
  * Should conform to coding standards, incremental development process, and
    other expectations.
  * Should have a sense of the community that it hopes to eventually foster, and
    there should be interest from members with different affiliations /