debuginfo: Generate cross-crate unique type identifiers for debuginfo types.

With this change, rustc creates a unique type identifier for types in debuginfo. These type identifiers are used by LLVM to correctly handle link-time-optimization scenarios but also help rustc with dealing with inlining from other crates. For more information, see the documentation block at the top of librustc/middle/trans/debuginfo.rs.

Fixes #13681.
debuginfo: Fix issue with unique type IDs not being passed to LLVM for LLVM 3.4
auto merge of #14819 : michaelwoerister/rust/unique_type_id, r=alexcrichton

With this change, rustc creates a unique type identifier for types in debuginfo. These type identifiers are used by LLVM to correctly handle link-time-optimization scenarios but also help rustc with dealing with inlining from other crates. For more information, see the documentation block at the top of librustc/middle/trans/debuginfo.rs and also [my blog post about the topic](http://michaelwoerister.github.io/2014/06/05/rust-debuginfo-and-unique-type-identifiers.html). This should fix the LTO issues that have been popping up lately. 

The changes to the debuginfo module's inner workings are also improved by this. Metadata uniquing of pointer types is not handled explicitly instead of relying on LLVM doing the right thing behind the scenes, and region parameters on types should not lead to metadata duplication anymore.

There are two things that I'd like to get some feedback on:
1. IDs for named items consist of two parts: The [Strict Version Hash](https://github.com/mozilla/rust/blob/0.10/src/librustc/back/svh.rs#L11) of their defining crate and the AST node id of their definition within that crate. My question is: Is the SVH a good choice for identifying the crate? Is it even going to stay? The [crate-id RFC](https://github.com/rust-lang/rfcs/pull/109) got me confused.
2. Unique Type Identifiers can be arbitrary strings and right now the format is rather verbose. For debugging this is nice, because one can infer a lot about a type from the type id alone (it's more or less a signature). For deeply nested generics, id strings could get rather long though. One option to limit the id size would be to use some hashcode instead of the full id (anything that avoids collision as much as possible). Another option would be to use a more compact representation, like ty_encode. This reduces size but also readability.
Since these ID's only show up in LLVM IR, I'm inclined to just leave in the verbose format for now, and only act if sizes of rlibs become a problem.
rustc: Allow safe access of shareable static muts

Taking a shareable loan of a `static mut` is safe if the type contained in the
location is ascribes to `Share`. This commit removes the need to have an
`unsafe` block in these situations.

Unsafe blocks are still required to write to or take mutable loans out of
statics. An example of code that no longer requires unsafe code is:

    use std::sync::atomics;

    static mut CNT: atomics::AtomicUint = atomics::INIT_ATOMIC_UINT;

    let cnt = CNT.fetch_add(1, atomics::SeqCst);

As a consequence of this change, this code is not permitted:

    static mut FOO: uint = 30;

    println!("{}", FOO);

The type `uint` is `Share`, and the static only has a shareable loan taken out
on it, so the access does not require an unsafe block. Writes to the static are
still unsafe, however, as they can invoke undefined behavior if not properly
synchronized.

Closes #13232
log: Avoid undefined behavior with LOG_LEVEL

As I have recently learned from aturon, it is undefined behavior to have any
unsynchronized access exected in parallel with an unsynchronized write. This
sort of behavior was possibly invoked by liblog during initialization. The log
level constant has been altered to become an atomic variable which prevents
undefined behavior.
Fix fall out of previous changes