Add garbage collector to std::gc

Not ready for merging.

## Summary

Tracing non-generational task-local GC, with stop-the-task non-incremental collections. The GC stores nothing inline in on values, and so doesn't need a header and a change of representation of generic types (like `@` does).

Includes two new modules `std::{libvec, uniq}` for examples of library defined versions of `~[]` and `~` respectively, which use the rooting API defined in `std::gc` to properly hold references to GC pointers (unlike `~`, `@`, `~[]` and `@[]`). (These modules are mostly demonstrations, not necessarily designed for landing.)

**Note**: when looking over this code, keep in mind I have pretty much no idea what I'm doing, so if something seems stupid, unconventional or silly; it almost certainly is.

## Details

This adds a `#[managed]` annotation and an intrinsic `reachable_new_managed::<T>() -> bool` (cf. the old `owns_managed` intrinsic, renamed to `owns_at_managed` in this PR). The intrinsic is *designed* to check whether a type contains any `#[managed]` annotated types, so that the library types can avoid touching the GC if they aren't storing GC'd pointers

The GC is conservative on the stack: when checking for GC'd references on the stack, it will scan every word and any bitpattern that matches the pointer to the start of a GC'd pointer or one of the other pointer types will be considered a valid region.

It does support finalisers, which are just run on the memory when a pointer is determined to be unused; so `Gc<T>` uses this to run the destructor of `T` (if it has one).

The rooting API mentioned above is simply a function `register_root_changes<T>(removals: &[*T], additions: &[(*T, uint, TraceFunc)])` which lets us indicate that certain regions are no longer possibly rooting `Gc`s, and add regions `(*T, uint, TraceFunc) == (start pointer, metadata, function to start tracing)` that possibly are rooting `Gc`s. The trick with this API that stops us having to scan everything is being generic: it knows the type `T` a pointer contains and statically if a certain type `T` can contain `#[managed]` types via the intrinsic. So if `T` can't contain managed pointers, there's no need to register it with the GC, so all one needs to do to make things GC safe is (unconditionally) pass a pointer of the appropriate to the relevant memory regions and the `std::gc` library will automatically figure out (by calling the intrinsic) if it actually needs to register those regions. In particular, this means that programs that never use any GC'd types can have the GC code removed, because nothing will call it. (`register_root_changes` will be inlined and reduce to a no-op for non-managed types.) 

The metadata mentioned above is arbitrary (not examined by the GC) and can be set with `update_metadata`, this is essentially just designed to allow storing the length of vectors for tracing.

There are a few commits which act as an example for this API: I add the library vector type from strcat's rust-core, and then make the appropriate adjustments to make it GC safe (5 calls to `register_root_changes`), and also add an equivalent to `~`, `std::uniq::Uniq<T>` which is similarly GC-safe.

Unfortunately to support tracing, these types (`Uniq` and `Vec`) require a `Trace` bound on their contents, which is unfortunate, as they *should* be allowed to store non-tracable types if those types don't contain any `Gc<T>` pointers.

## Problems

- [x] *Done: lang items to register/deregister ~ allocations as appropriate* On that note... The **largest problem** with this PR is `~`, `@`, `~[]` and `@[]` do not act as roots. That is, having a pile of `Gc` pointers such that the only reference to them is a `~[Gc<int>]` will cause them to be considered unreachable and be garbage collected. As such, I've marked any method that could demonstrate a symptom of this problem (the various `.borrow`s) as `unsafe`. It's probably possible to do something with lang-items to get them to work... but, personally having them as library types seems simpler (look at how simple it was to add GC support to the two new modules: adding support to `Rc` would be as easy as it was to add to `Uniq` too.)
- [ ] similarly, global variables are not considered (seems like this shouldn't be supported by default: the user can call `register_root_changes` themselves to register one if they must)
- [x] *Done: scanned conservatively for now* --- task-local storage is not considered
- [ ] The GC is *slow* (about ~~20x~~ ~~6.5x~~ ~~5x~~ 4x slower than straight malloc for a microbenchmark of just doing a lot of allocations) and memory hungry. Reasons:
  - *Done: allocations less than 1 MB are (fairly basically) cached and reused giving a 50% performance boost* --- every allocation is a call to malloc, and every unreachable pointer is actually `free`d (I'm working on caching unused allocations now)
  - `std::trie` is slow, and I'm using it wrong, and it's possibly not the best data structure.
     - *Done: caching* --- the GC actually spends most of it's time in trie methods like `insert` and `remove`, if allocations were cached and not removed from the `trie` this would help a lot
     - it breaks a `uint` into chunks of 4 bits from the most significant bit, and most `malloc`'d pointers agree on their first 30 bits, so we spend a lot of time just traversing that with no ability to distinguish between keys (very hard to fix, since the only way to get the correct order is to traverse in this manner; requires a path-compressing trie)
     - it could just do with some general optimisation (possibly with some `unsafe`)
  - it has to do a `Local::borrow(None::<Task>)` twice on every allocation (to retrieve and return the GC, see below) (although `perf` indicates the *vast* majority of the time is spent in collection)
- [x] *Done: some restricted & careful unsafe code* --- It has to actually remove the task-local GC from the task struct during allocation and collection (so that we can unborrow the `Task` because that would be far worse than what I'm about to describe), which means that any finalisers that need to call into the GC (like those that need to unregister roots) will crash, in particular, a type like `Gc<Vec<Gc<T>>>` will fail because the `Vec` destructor calls `register_root_changes`.
- [ ] `fail!`-ing finalisers aren't considered at all, and also cause failure. (Both of these can hit the double-unwinding and cause an abort.)
- [ ] finalisers are memory unsafe w.r.t. to cyclic objects, but I'm not 100% sure this is a problem: we already restrict destructors and require `#[unsafe_destructor]` so it's the users "fault" if they crash due to this
- [ ] it requires more instrumentation & statistics
- [ ] the GC could be generational, but isn't currently. There is a pseudo-API designed to (in theory) support this, defined on `Gc` (all are `Gc<T> -> &T`):
  - `borrow` for only `Freeze` types, that does not have any write barriers
  - `borrow_write_barrier`, the general borrow that does have a write barrier; although in theory the write barrier could be elided when `owns_new_managed::<T>` is false (since any writes couldn't add/change references to `Gc` pointers)
  - `borrow_no_write_barrier`; same as `.borrow`, but implemented for all `T` and `unsafe`, designed for when someone is definitely sure they're going to be reading only, or are not going to be changing any `Gc` references.
- [ ] not enough in-source tests (easy enough to fix)
- [ ] The added modules `std::{uniq, libvec}` have no documentation or tests (since they're just designed to exhibit the rooting API)
- [ ] The tracing API means `Uniq` and `Vec` are less flexible that desirable (which flows downstream to any generic users of them) because they require a `Trace` bound to be able to register a handle to run when discovered by a conservative scan. Possible solutions:
  -  having separate non-trace constructors (and non-trace `.push` and `.pop` for `Vec`!) but this would then require similar contortions downstream; 
  - some sort of explicit `TraceOrNonManaged` bound (which would also require downstream generic to have that bound)
  - have the compiler enforce that `Gc` can only go into `Trace` types (a little like `transmute` requires types of the same size)
  - have the compiler generate trace glue like drop glue, etc., and then retrieve this for tracing (would require a `call_trace_glue` intrinisic, but then we'd have to have some way to get the appropriate types and information into it).
- [ ] doesn't support interior pointers 

Because of this list (mainly the memory-unsafety problem with `~` etc not acting as roots), I've marked `std::gc::Gc` as `#[experimental]`.