This commit fixes some oversights in the Makefile where rustc could be
invoked without some of its dependencies yet in place.  (I encountered
the problem in practice; its not just theoretical.)

As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one
writes an invocation of rustc where $(1) is the stage number $(2) is
the target triple $(3) is the host triple.  (Other uses of the macro
may plug in actual values or different parameters in for those three
formal parameters.)

When you have invocations of $(STAGE...), you need to make sure that
its dependences are satisfied; otherwise, if someone is using `make
-jN` for certain (large-ish) `N`, one can encounter situations where
GNU make attempts to invoke `rustc` before it has actually copied some
of its libraries into place, such as libmorestack.a, which causes a
link failure when the rustc invocation attempts to link in those
libraries.

In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3),
which is described in Makefile.in as "Prerequisites for using the
stageN compiler to build target artifacts"

----

In addition to adding the extra dependences on TSREQ..., I also
replaced occurrences of the pattern:

    TSREQ$(1)_T_$(2)_H_$(3)
    $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2))
    $$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2))

with:

    SREQ$(1)_T_$(2)_H_$(3)

which is equivalent to the above, as defined in Makefile.in

----

Finally, for the cases where TSREQ was missing in tests.mk, I went
ahead and put in a dependence on SREQ rather than just TSREQ, since it
was not clear to me how one could expect to compile those cases
without stdlib and extralib.

(It could well be that I should have gone ahead and done the same in
 other cases where I saw TSREQ was missing, and put SREQ in those
 cases as well.  But this seemed like a good measure for now, without
 needing to tax my understanding of the overall makefile
 infrastructure much further.)

Namely, switched in many places to using GNU make provided functions
for directory listing and text processing, rather than spawning a
shell process to do that work.

In the process of the revision, learned about Target-specific
variables, which were very applicable to INSTALL_LIB (which, on a
per-recipe basis, was always receiving the same actual arguments for
its first two formal parameters in every invocation).

  http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html

(We might be able to make use of those in future refactorings.)

----

Also adds a cleanup pass to get-snapshot.py as well, since the same
problem arises when we unpack libraries from the snapshot archive into
a build directory with a prior snapshot's artifacts.  (I put this step
into the python script rather than the makefile because I wanted to
delay the cleanup pass until after we have at least successfully
downloaded the tarball.  That way, if the download fails, you should
not destroy the previous unarchived snapshot libraries and build
products.)

----

Also reverted whitespace changes to minimize diff.
I plan to put them back in in a dedicated commit elsewhere.

When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)

When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.

The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.

It is suffering from a bad case of megabitrot.

This only changes the directory names; it does not change the "real"
metadata names.

For cross compiling to targets that don't want to build a compiler

Add Brian Leibig to AUTHORS.txt for REPL contributions