Rename and move ty_param_substs_and_ty
Rename ty_param_bounds_and_ty to Polytype
Use the slice repr for ~[T]
DST coercions
Remove mutability from ty_vec
DST coercions pt 2
Tests for dst-ish bugs.
Remove special cases for vec/str
Remove ExprVStore, includes coercions on return types etc.

[breaking-change] We now use the minimal type for reference to vec types, specifically &[T, ..n] whereas we used to use &[T]. The fixed size type will always coerce implicitly to the unsized version so this change is mostly invisible, e.g., `let x: &[int] = &[0i, 1, 2, 3];` will still type check.

However, the compiler will not coerce unless it has to and is not smart enough to try coercing when trying to unify types. This means that if the compiler has to unify &[T, ..m] and &[T, ..n] where m != n, it will fail whereas previously both expressions would have type &[T] and unification would succeed.

A practical example is that if you have an if/else statement which might have different vec lengths, you will need to use a temporary variable to force a coercion. E.g.,

```
if foo {
    &[0i, 1, 2, 3]
} else {
    &[]
}
```

will now cause an error. The fix is

```
if foo {
    let result: &[int] = &[0i, 1, 2, 3];
    result
} else {
    let result: &[int] = &[];
    result
}
```
Pass tests (mostly test changes)
Address a bunch of TODOs from earlier and remove debugging printlns, etc.
Tests (and changes for tests).
Address review comments.
Rebasing errors and misc changes.

[breaking_change] The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.

[breaking_change] The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects, and it may just be a bug. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
use my new coercion infra for trait coercions and allow DST structs with raw trait fields.
Remove AutoBorrowObj
Tidy up a bit
smaht<Trait>
Tests.

[breaking-change] The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
review changes