install.sh may falsely believe installed `rustc` is runnable on OS X

[brson]

cc #15550

The last thing install.sh does is attempt to run rustc to verify the installation works. On OS X, when install.sh is run from the build directory (as in make install), if the dynamic loader doesn't find the correct libraries, then it will apparently fall back to looking in the original location of the libraries; it then succeeds to link to the wrong library, and in turn believes the installation was successful.

cc @alexcrichton @pnkfelix

[brson]

It's not clear to me when this error might happen. Specifically, if install.sh sets LD_LIBRARY_PATH correctly, as it does in #15550, it should be very unusual for the dynamic linker to not find the correct libraries.

[pnkfelix]

The main observable error here is that install.sh fails to print out alex's message about it being necessary to add a path to one's DYLD_LIBRARY_PATH (since the first attempt on the pre-existing DYLD_LIBRARY_PATH succeeded, but only because the current-working-directory misled it).

I think we can easily make the check in install.sh more robust. One strategy I thought of this morning: instead of running the runability check from the root of the distribution (aka the build tree when one is using make install), instead of that, make a fresh empty subdirectory in the current directory, and then cd into that before each rustc runnabiilty check. That way, as long as the embedded path does not do anything funny like have relative references to the parent directory via ../path/to/libs/, then that should be able to run consistently in both the build tree and also in an untarred release.

---

I was a little perturbed at the nature of the path that was embedded in the rustc being distributed, since it seemed to embed build artifacts unrelated to the target prefix. So it might be nice to see if that can be changed. But that is not strictly speaking the goal of this ticket.