Reduces time to build stage0 from 11:30 to 9:40 on my machine.

The long hash just takes up space and you can discover the main hash through the
`rustc --version verbose` command.

The compiler will no longer insert a hash or version into a filename by default.
Instead, all output is simply based off the crate name being compiled. For
example, a crate name of `foo` would produce the following outputs:

* bin => foo
* rlib => libfoo.rlib
* dylib => libfoo.{so,dylib} or foo.dll
* staticlib => libfoo.a

The old behavior has been moved behind a new codegen flag,
`-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and
a crate name of `foo`, the following outputs would be generated:

* bin => foo (same old behavior)
* rlib => libfoobar.rlib
* dylib => libfoobar.{so,dylib} or foobar.dll
* staticlib => libfoobar.a

The makefiles have been altered to pass a hash by default to invocations of
`rustc` so all installed rust libraries will have a hash in their filename. This
is done because the standard libraries are intended to be installed into
privileged directories such as /usr/local. Additionally, it involves very few
build system changes!

RFC: 0035-remove-crate-id
[breaking-change]

This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.

This involved a few changes to the local build system:

* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.

Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.

This change brings linux/mac installations in line with windows installations
where rpath is not possible.

Closes #11747
[breaking-change]

This involved a few changes to the local build system:

* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

This change was spliced out of #14832 to consist of just the fixes to running
tests without an rpath setting embedded in executables.

Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added
RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup.

`HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)`
both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which
is still being set the same way that it was before, to one of either
HOST/TARGET depending on what stage we are building).  Namely, the format
is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>"

What this commit does:

* Pass both of the (newly introduced) HOST and TARGET rpath setup vars
  to `maketest.py`

* Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself
  Instead, it passes along the HOST and TARGET rpath setup vars in
  environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV`

* Also, pass the current stage number to maketest.py; it in turn
  passes it (via an env var) to run-make tests.

  This allows the run-make tests to selectively change behavior
  (e.g. turn themselves off) to deal with incompatibilities with
  e.g. stage1.

* Cleanup: Distinguish in tools.mk between the command to run (`RUN`)
  and the file to generate to drive that command (`RUN_BINFILE`).  The
  main thing this enables is that `RUN` can now setup the
  `TARGET_RPATH_ENV` without having to dirty up the runner code in
  each of the `run-make` Makefiles.

* Cleanup: Factored out commands to delete dylib/rlib into
  REMOVE_DYLIBS/REMOVE_RLIBS.

  There were places where we were only calling `rm $(call DYLIB,foo)`
  even though we really needed to get rid of the whole glob (at least
  based on alex's findings on #13753 that removing the symlink does not
  suffice).

  Therefore rather than peppering the code with the awkward
  `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common
  `REMOVE_DYLIBS` user function that expands into that when called.
  After I adding an analogous `REMOVE_RLIBS`, I changed all of the
  existing calls that rm dylibs or rlibs to use these routines
  instead.

  Note that the latter is not a true refactoring since I may have
  changed cases where it was our intent to only remove the sym-link.
  (But if that is the case, then we need to more deeply investigate
  alex's findings on #13753 where the system was still dynamically
  loading up the non-symlinked libraries that it finds on the load
  path.)

* Added RPATH_LINK_SEARCH command and use it on Linux.

  On some platforms, namely Linux, when you have libboot.so that has
  its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the
  linker still complains when you do the link step and it does not
  know where to find libraries that libboot.so depends upon that live
  in HOSTDIR (think e.g. librustuv.so).

  As far as I can tell, the GNU linker will consult the
  LD_LIBRARY_PATH as part of the linking process to find such
  libraries.  But if you want to be more careful and not override
  LD_LIBRARY_PATH for the `gcc` invocation, then you need some other
  way to tell the linker where it can find the libraries that
  libboot.so needs.  The solution to this on Linux is the
  `-Wl,-rpath-link` command line option.

  However, this command line option does not exist on Mac OS X, (which
  appears to be figuring out how to resolve the libboot.dylib
  dependency by some other means, perhaps by consulting the rpath
  setting within libboot.dylib).

  So, in order to abstract over this distinction, I added the
  RPATH_LINK_SEARCH macro to the run-make infrastructure and added
  calls to it where necessary to get Linux working.  On architectures
  other than Linux, the macro expands to nothing.

* Disable miscellaneous tests atop stage1.

* An especially interesting instance of the previous bullet point:
  Excuse regex from doing rustdoc tests atop stage1.

  This was a (nearly-) final step to get `make check-stage1` working
  again.

  The use of a special-case check for regex here is ugly but is
  analogous other similar checks for regex such as the one that landed
  in PR #13844.

  The way this is written, the user will get a reminder that
  doc-crate-regex is being skipped whenever their rules attempt to do
  the crate documentation tests.  This is deliberate: I want people
  running `make check-stage1` to be reminded about which cases are
  being skipped.  (But if such echo noise is considered offensive, it
  can obviously be removed.)

* Got windows working with the above changes.

  This portion of the commit is a cleanup revision of the (previously
  mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH
  setup and extension is handled in order to accommodate Windows' (1.)
  use of `$PATH` for that purpose and (2.) use of spaces in `$PATH`
  entries (problematic for make and for interoperation with tools at
  the shell).

* In addition, since the code has been rearchitected to pass the
  HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh
  environment-variable setting command, there is no need to for the
  convert_path_spec calls in maketest.py, which in fact were put in
  place to placate Windows but were now causing the Windows builds to
  fail.  Instead we just convert the paths to absolute paths just like
  all of the other path arguments.

Also, note for makefile hackers: apparently you cannot quote operands
to `ifeq` in Makefile (or at least, you need to be careful about
adding them, e.g. to only one side).

After removing absolute rpaths, cross compile builds (notably the nightly
builders) broke. This is because the RPATH was pointing at an empty directory
because only the rustc binary is copied over, not all of the target libraries.
This modifies the cross compile logic to fixup the rpath of the stage0
cross-compiled rustc to point to where it came from.

Concerns have been raised about using absolute rpaths in #11746, and this is the
first step towards not relying on rpaths at all. The only current use case for
an absolute rpath is when a non-installed rust builds an executable that then
moves from is built location. The relative rpath back to libstd and absolute
rpath to the installation directory still remain (CFG_PREFIX).

Closes #11746
Rebasing of #12754

This also changes some of the download links in the documentation
to 'nightly'.

Trying to reduce the complexity of installation

Also, add more distcheck tests

This involves passing through LD_LIBRARY_PATH through more places, specifically
in the compiletest, run-make, and doctest runners.

LLVM's tools are not contained in the local directory if --llvm-root is used by
the ./configure script. This fixes the installation path to be the root provided
by --llvm-root.

LLVM's tools are not contained in the local directory if --llvm-root is used by
the ./configure script. This fixes the installation path to be the root provided
by --llvm-root.

The tag marks were missing, and `make tips` didn't work.

Just so it's easier to find.

Because the build system treats Makefile.in and the .mk files slightly
differently (.in is copied, .mk are included), this makes the system
more uniform. Fewer build system changes will require a complete
reconfigure.

This way of doing snapshots hasn't been used since 2011.

'make help' is implemented in a fairly ridiculous way, using awk
to parse comments out of Makefile.in and displaying them.

This is blocking a snapshot because the stage0 target compiler comes from a
stage1 host compiler. This means that the stage0 compiler doesn't actually
understand the -Z prefer-dynamic flag and is dying as a result.

This will get added back to stage0 after a snapshot.

Move them all behind a new -C switch. This migrates some -Z flags and some
top-level flags behind this -C codegen option.

The -C flag takes values of the form "-C name=value" where the "=value" is
optional for some flags.

Flags affected:

* --llvm-args           => -C llvm-args
* --passes              => -C passes
* --ar                  => -C ar
* --linker              => -C linker
* --link-args           => -C link-args
* --target-cpu          => -C target-cpu
* --target-feature      => -C target-fature
* --android-cross-path  => -C android-cross-path
* --save-temps          => -C save-temps
* --no-rpath            => -C no-rpath
* -Z no-prepopulate     => -C no-prepopulate-passes
* -Z no-vectorize-loops => -C no-vectorize-loops
* -Z no-vectorize-slp   => -C no-vectorize-slp
* -Z soft-float         => -C soft-float
* -Z gen-crate-map      => -C gen-crate-map
* -Z prefer-dynamic     => -C prefer-dynamic
* -Z no-integrated-as   => -C no-integrated-as

As a bonus, this also promotes the -Z extra-debug-info flag to a first class -g
or --debuginfo flag.

* -Z debug-info         => removed
* -Z extra-debug-info   => -g or --debuginfo

Closes #9770
Closes #12000