Upgrade LLVM

This comes with a number of fixes to be compatible with upstream LLVM:

* Previously all monomorphizations of "mem::size_of()" would receive the same
  symbol. In the past LLVM would silently rename duplicated symbols, but it
  appears to now be dropping the duplicate symbols and functions now. The symbol
  names of monomorphized functions are now no longer solely based on the type of
  the function, but rather the type and the unique hash for the
  monomorphization.

* Split stacks are no longer a global feature controlled by a flag in LLVM.
  Instead, they are opt-in on a per-function basis through a function attribute.
  The rust #[no_split_stack] attribute will disable this, otherwise all
  functions have #[split_stack] attached to them.

* The compare and swap instruction now takes two atomic orderings, one for the
  successful case and one for the failure case. LLVM internally has an
  implementation of calculating the appropriate failure ordering given a
  particular success ordering (previously only a success ordering was
  specified), and I copied that into the intrinsic translation so the failure
  ordering isn't supplied on a source level for now.

* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,
  etc.
configure: Enable libc++ with LLVM with clang

When clang is enabled, also pass through --enable-libcpp to LLVM's configure
command line to help it pick up the most recent c++ runtime library. This also
changes the mklldeps.py script to pick up on whether LLVM was linked against
stdc++ or c++ based on the --cxxflags that llvm-config prints.

In an ongoing attempt to update LLVM, the bots need to update their C compilers
to something that supports c++11 (LLVM recently switched). The OSX bots are
running Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently
the libstdc++ is too old (even on the most updated command line tools) for LLVM,
but using libc++ instead appears to work just fine.
configure: Enable clang for older OSX gcc versions

OSX often has a more recent version of clang than it does for GCC. When an older
version of gcc is detected on OSX, the --enable-clang flag is implicitly
enabled.
etc: The --system-libs flag is LLVM 3.5+

Older version of LLVM did not have this flag, so we need to fall back to our
previous library detection when using older versions of LLVM.
llvm: Add an option to statically link libstdc++

The goal of the snapshot bots is to produce binaries which can run in as many
locations as possible. Currently we build on Centos 6 for this reason, but with
LLVM's update to C++11, this reduces the number of platforms that we could
possibly run on.

This adds a --enable-llvm-static-stdcpp option to the ./configure script for
Rust which will enable building a librustc with a static dependence on
libstdc++. This normally isn't necessary, but this option can be used on the
snapshot builders in order to continue to make binaries which should be able to
run in as many locations as possible.
rustc: Hint to the linker about static/shared libs

If a linker finds both a static and a dynamic version of the same library, then
the linker often chooses the dynamic version. This is surprising when a native
library is specified as being "static" in rust source. This modifies the linker
command line to obey the hints given in rust source files and instructing the
linker to prefer a particular version of a found library.

Unfortunately, this patch has no effect on osx because the linker supports
no such hint, and it also has no effect on windows because the linker apparently
just ignores it. For now this is predominately used to enable the previous patch
of linking to libstdc++ statically, but more support would need to be added for
this in the future if we wanted to officially support it.

cc #12557 (doesn't close because it doesn't support OSX and windows)
std: Fail more gracefully on thread spawn errors

On windows, correctly check for errors when spawning threads, and on both
windows and unix handle the error more gracefully rather than printing an opaque
assertion failure.

Closes #13589
Fix smallest-hello-world.rs interaction with `puts`

It now hands `puts` a zero-terminated string, like it expects.

Fix #13603.
debuginfo: Clamp the maximum dwarf version to 3

This is a consequence of #13611 and our bots running a "fairly old" gdb which
doesn't understand the newer versions of dwarf.
vim: Add StrBuf as type to hilighting
auto merge of #13513 : alexcrichton/rust/up-llvm, r=brson

This is a bit of an interesting upgrade to LLVM. Upstream LLVM has started using C++11 features, so they require a C++11 compiler to build. I've updated all the bots to have a C++11 compiler, and they appear to be building LLVM successfully:

* Linux bots - I added gcc/g++ 4.7 (good enough)
* Android bots - same as the linux ones
* Mac bots - I installed the most recent command line tools for Lion which gives us clang 3.2, but LLVM wouldn't build unless it was explicitly asked to link to `libc++` instead of `libstdc++`. This involved tweaking `mklldeps.py` and the `configure` script to get things to work out
* Windows bots - mingw-w64 has gcc 4.8.1 which is sufficient for building LLVM (hurray!)
* BSD bots - I updated FreeBSD to 10.0 which brought with it a relevant version of clang.

The largest fallout I've seen so far is that the test suite doesn't work at all on FreeBSD 10. We've already stopped gating on FreeBSD due to #13427 (we used to be on freebsd 9), so I don't think this puts us in too bad of a situation. I will continue to attempt to fix FreeBSD and the breakage on there.

The LLVM update brings with it all of the recently upstreamed LLVM patches. We only have one local patch now which is just an optimization, and isn't required to use upstream LLVM. I want to maintain compatibility with LLVM 3.3 and 3.4 while we can, and this upgrade is keeping us up to date with the 3.5 release. Once 3.5 is release we will in theory no longer require a bundled LLVM.
Reduce HashMap allocations.
Replace all ~"" with "".to_owned()
std: Fix demangling with middle special chars

Previously, symbols with rust escape sequences (denoted with dollar signs)
weren't demangled if the escape sequence showed up in the middle. This alters
the printing loop to look through the entire string for dollar characters.
auto merge of #13607 : brson/rust/to_owned, r=brson

Continues https://github.com/mozilla/rust/pull/13548
auto merge of #13606 : alexcrichton/rust/better-thread-errors, r=brson

On windows, correctly check for errors when spawning threads, and on both
windows and unix handle the error more gracefully rather than printing an opaque
assertion failure.

Closes #13589
auto merge of #13608 : tbu-/rust/pr_smallesthello, r=alexcrichton

It now hands `puts` a zero-terminated string, like it expects.

Fix #13603.
std: Add an experimental connect_timeout function

This adds a `TcpStream::connect_timeout` function in order to assist opening
connections with a timeout (cc #13523). There isn't really much design space for
this specific operation (unlike timing out normal blocking reads/writes), so I
am fairly confident that this is the correct interface for this function.

The function is marked #[experimental] because it takes a u64 timeout argument,
and the u64 type is likely to change in the future.
auto merge of #13604 : alexcrichton/rust/connect-timeout, r=brson

This adds a `TcpStream::connect_timeout` function in order to assist opening
connections with a timeout (cc #13523). There isn't really much design space for
this specific operation (unlike timing out normal blocking reads/writes), so I
am fairly confident that this is the correct interface for this function.

The function is marked #[experimental] because it takes a u64 timeout argument,
and the u64 type is likely to change in the future.
auto merge of #13609 : richo/rust/str-type-vim, r=alexcrichton

It seems really weird to me when StrSlice and str highlight sanely, but StrBuf doesn't.

I think I added it to the right place.