[NFC] Fix some docs warnings

[hctim]

Summary

Fixes two minor issues in the docs present under ninja docs-llvm-html:

1 - A header is too small:

Warning, treated as error:
llvm/llvm/docs/Passes.rst:70:Title underline too short.

``-basic-aa``: Basic Alias Analysis (stateless AA impl)
------------------------------------------------------

2 - Multiple definitions on a non-anonymous target (llvm-dev mailing list):

Warning, treated as error:
llvm/llvm/docs/DeveloperPolicy.rst:3:Duplicate explicit target name: "llvm-dev mailing list".

[lattner]

Thanks!

llvm/docs/DeveloperPolicy.rst

 codebase can use newer versions of C++ as they get standardized. Requiring newer
 toolchains to build LLVM can be painful for those building LLVM; therefore, it
 will only be done through the following process:
 
   * It is a general goal to support LLVM and GCC versions from the last 3 years
     at a minimum. This time-based guideline is not strict: we may support much
     older compilers, or decide to support fewer versions.
 
-  * An RFC is sent to the `llvm-dev mailing list <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_
+  * An RFC is sent to the `llvm-dev mailing list`_
 
     - Detail upsides of the version increase (e.g. which newer C++ language or
       library features LLVM should use; avoid miscompiles in particular compiler
       versions, etc).
     - Detail downsides on important platforms (e.g. Ubuntu LTS status).
 
   * Once the RFC reaches consensus, update the CMake toolchain version checks as
     well as the :doc:`getting started<GettingStarted>` guide.  This provides a

 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
 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 <https://lists.llvm.org/mailman/listinfo/llvm-dev>`_.
+`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 
+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:
 
 * Experimental targets are not built by default (they need to be explicitly
   enabled at CMake time).
* The code must be free of contentious issues, for example, large
   following the :ref:`IR backwards compatibility`.
 
 * The code conforms to all of the policies laid out in this developer policy
   document, including license, patent, and coding standards.
 
 * The target should have either reasonable documentation on how it
   works (ISA, ABI, etc.) or a publicly available simulator/hardware
   (either free or cheap enough) - preferably both.  This allows
-  developers to validate assumptions, understand constraints and review code 
-  that can affect the target. 
+  developers to validate assumptions, understand constraints and review code
+  that can affect the target.
 
 In addition, the rules for a back-end to be promoted to **official** are:
 
 * The target must have addressed every other minimum requirement and
   have been stable in tree for at least 3 months. This cool down
   period is to make sure that the back-end and the target community can
   endure continuous upstream development for the foreseeable future.
 
* 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
+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
 -----------------------

  * Other infrastructure integration can be discussed on a case-by-case basis.
 
 Graduation to the mono-repo would follow existing processes and standards for
 becoming a first-class part of the monorepo.  Similarly, an incubating project
 may be eventually retired, but no process has been established for that yet.  If
 and when this comes up, please start an RFC discussion on llvm-dev.
 
 This process is very new - please expect the details to change, it is always
-safe to ask on the `llvm-dev mailing list
-<https://lists.llvm.org/mailman/listinfo/llvm-dev>`_ about this.
+safe to ask on the `llvm-dev mailing list`_ about this.
 
 Suggested disclaimer for the project README and the main project web page:
 
 ::
 
    This project is participating in the LLVM Incubator process: as such, it is
    not part of any official LLVM release.  While incubation status is not
    necessarily a reflection of the completeness or stability of the code, it

 need the binary redistribution clause), and as a contributor to the code that
 you agree that any contributions to these libraries be licensed under both
 licenses.  We feel that this is important for runtime libraries, because they
 are implicitly linked into applications and therefore should not subject those
 applications to the binary redistribution clause. This also means that it is ok
 to move code from (e.g.)  libc++ to the LLVM core without concern, but that code
 cannot be moved from the LLVM core to libc++ without the copyright owner's
 permission.
+
+.. _llvm-dev mailing list: http://lists.llvm.org/mailman/listinfo/llvm-dev

llvm/docs/Passes.rst

 function in the program, it simply queries to see how the alias analysis
 implementation answers alias queries between each pair of pointers in the
 function.
 
 This is inspired and adapted from code by: Naveen Neelakantam, Francesco
 Spadini, and Wojciech Stryjewski.
 
 ``-basic-aa``: Basic Alias Analysis (stateless AA impl)
-------------------------------------------------------
+-------------------------------------------------------
 
 A basic alias analysis pass that implements identities (two different globals
 cannot alias, etc), but does no stateful analysis.
 
 ``-basiccg``: Basic CallGraph Construction
 ------------------------------------------
 
 Yet to be written.