Track kind of closure in upvar categorization

Keep track of the kind of closure responsible for an upvar
Categorize upvars in `Fn` unboxed closures as freely aliasable

This causes borrowck to correctly reject mutation or mutable borrows
of upvars in `Fn` unboxed closures since the closure environment is
aliasable.

This also tracks the responsible closure in the aliasability
information returned and uses it to give a helpful diagnostic.

Closes issue #17780
Fix unit test that was illegally mutating an upvar
Add regression test for issue #17780
saner parameter order for reallocation functions

Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.

Closes #17837

[breaking-change]
remove crate_id attribute, add crate_name one

this is true as of https://github.com/rust-lang/rust/pull/15319
add mention of test attribute

Fixes #16413
auto merge of #17873 : steveklabnik/rust/gh16413, r=alexcrichton

A fix for the issues mentioned in https://github.com/rust-lang/rust/issues/16413
auto merge of #17784 : bkoropoff/rust/issue-17780, r=pcwalton

This fixes a soundness problem where `Fn` unboxed closures can mutate free variables in the environment.
The following presently builds:

```rust
#![feature(unboxed_closures, overloaded_calls)]

fn main() {
    let mut x = 0u;
    let _f = |&:| x = 42;
}
```

However, this is equivalent to writing the following, which borrowck rightly rejects:

```rust
struct F<'a> {
    x: &'a mut uint
}

impl<'a> Fn<(),()> for F<'a> {
    #[rust_call_abi_hack]
    fn call(&self, _: ()) {
        *self.x = 42; // error: cannot assign to data in a `&` reference
    }
}

fn main() {
    let mut x = 0u;
    let _f = F { x: &mut x };
}
```

This problem is unique to unboxed closures; boxed closures cannot be invoked through an immutable reference and are not subject to it.

This change marks upvars of `Fn` unboxed closures as freely aliasable in mem_categorization, which causes borrowck to reject attempts to mutate or mutably borrow them.

@zwarich pointed out that even with this change, there are remaining soundness issues related to regionck (issue #17403).  This region issue affects boxed closures as well.

Closes issue #17780
Properly translate boolean statics to be stored as i8

While booleans are represented as i1 in SSA values, LLVM expects them
to be stored/loaded as i8 values. Using i1 as we do now works, but
kills some optimizations, so we should switch to i8, just like we do
everywhere else.

Fixes #16959.
auto merge of #17870 : thestinger/rust/alloc, r=eddyb

Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.

Closes #17837

[breaking-change]
auto merge of #17875 : dotdash/rust/static_bool, r=alexcrichton

While booleans are represented as i1 in SSA values, LLVM expects them
to be stored/loaded as i8 values. Using i1 as we do now works, but
kills some optimizations, so we should switch to i8, just like we do
everywhere else.

Fixes #16959.
rustc: Reformat check_const with modern style

Remove a bunch of two-space tabs
rustc: Add `const` globals to the language

This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.

The semantics of these three kinds of globals are:

* A `const` does not represent a memory location, but only a value. Constants
  are translated as rvalues, which means that their values are directly inlined
  at usage location (similar to a #define in C/C++). Constant values are, well,
  constant, and can not be modified. Any "modification" is actually a
  modification to a local value on the stack rather than the actual constant
  itself.

  Almost all values are allowed inside constants, whether they have interior
  mutability or not. There are a few minor restrictions listed in the RFC, but
  they should in general not come up too often.

* A `static` now always represents a memory location (unconditionally). Any
  references to the same `static` are actually a reference to the same memory
  location. Only values whose types ascribe to `Sync` are allowed in a `static`.
  This restriction is in place because many threads may access a `static`
  concurrently. Lifting this restriction (and allowing unsafe access) is a
  future extension not implemented at this time.

* A `static mut` continues to always represent a memory location. All references
  to a `static mut` continue to be `unsafe`.

This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:

* Statics may no longer be used in patterns. Statics now always represent a
  memory location, which can sometimes be modified. To fix code, repurpose the
  matched-on-`static` to a `const`.

      static FOO: uint = 4;
      match n {
          FOO => { /* ... */ }
          _ => { /* ... */ }
      }

  change this code to:

      const FOO: uint = 4;
      match n {
          FOO => { /* ... */ }
          _ => { /* ... */ }
      }

* Statics may no longer refer to other statics by value. Due to statics being
  able to change at runtime, allowing them to reference one another could
  possibly lead to confusing semantics. If you are in this situation, use a
  constant initializer instead. Note, however, that statics may reference other
  statics by address, however.

* Statics may no longer be used in constant expressions, such as array lengths.
  This is due to the same restrictions as listed above. Use a `const` instead.

[breaking-change]

[rfc]: https://github.com/rust-lang/rfcs/pull/246
core: Convert statics to constants
sync: Convert statics to constants
unicode: Make statics legal

The tables in libunicode are far too large to want to be inlined into any other
program, so these tables are all going to remain `static`. For them to be legal,
they cannot reference one another by value, but instead use references now.

This commit also modifies the src/etc/unicode.py script to generate the right
tables.
collections: Convert statics to constants
libc: Convert all statics to constant

This crate is largely just one giant header file, so there's no need for any of
these values to actually have a memory location, they're all just basically a
regular #define.
rand: Convert statics to constants

This leaves the ziggurat tables as `pub static` as they're likely too large to
want to go into the metadata anyway.