Enum layout optimizations

This extends the nullable enum opt to traverse beyond just the first level to find possible fields to use as the discriminant. So now, it'll work through structs, tuples, and fixed sized arrays. This also introduces a new lang item, NonZero, that you can use to wrap raw pointers or integral types to indicate to rustc that the underlying value is known to never be 0/NULL. We then use this in Vec, Rc and Arc to have them also benefit from the nullable enum opt.

As per https://github.com/rust-lang/rfcs/pull/499 NonZero is not exposed via the `libstd` facade.

```
x86_64 Linux:
                        T       Option<T> (Before)      Option<T> (After)
----------------------------------------------------------------------------------
Vec<int>                24          32                      24
String                  24          32                      24
Rc<int>                 8           16                      8
Arc<int>                8           16                      8
[Box<int>, ..2]         16          24                      16
(String, uint)          32          40                      32
```

Fixes #19419.
Fixes #13194.
Fixes #9378.
Fixes #7576.
It feels like should be an error to have `NonZero<T>` applied to any `T` that is not a pointer or an integral value. We can sort of enforce this in the library by making a trait:

```
pub trait Zeroable { }
impl<T> Zeroable for *mut T { }
impl<T> Zeroable for *const T { }
impl<T> Zeroable for uint { }
...

pub struct NonZero<T:Zeroable> { ... }
```

Unfortunately, this is not bullet proof, as the trait must be public so that it can appear in a public API, which means others could implement it. However, since `NonZero` is not fully exposed, perhaps we can live with that for now.

Anyway, it seems like a bad coding pattern to apply `NonZero` to some type you don't control, is there any known use case for that?