RFC: Add a thread local storage module, std::tls

Introduce a new thread local storage module to the standard library, `std::tls`,
providing:

* Scoped TLS, a non-owning variant of TLS for any value.
* Owning TLS, an owning, dynamically initialized, dynamically destructed
  variant, similar to `std::local_data` today.

[Rendered](https://github.com/alexcrichton/rfcs/blob/tls-overhaul/text/0000-tls-overhaul.md)
I've added a few more benchmarks, and these are the results:

```
test dynamic         ... bench:      1573 ns/iter (+/- 64)
test global_variable ... bench:      1797 ns/iter (+/- 16)
test local_data      ... bench:      5246 ns/iter (+/- 14)
test local_variable  ... bench:      1531 ns/iter (+/- 2)
test noop            ... bench:       271 ns/iter (+/- 3)
test os              ... bench:      9787 ns/iter (+/- 55)
test scoped          ... bench:      1529 ns/iter (+/- 7)
test statik          ... bench:      1543 ns/iter (+/- 5)
test thread_local    ... bench:      1543 ns/iter (+/- 1)
```

While I don't dispute that a dynamically initialized variable has more instructions on the fast path than a statically initialized one, it seems that the impact is quite minor. These numbers make it look like a global variable is a tad bit slower! If the cost of measuring the benchmarking loop is significant in terms of measurements, then I would expect the conclusion to be that the unit being benchmarked is quite fast.

I'd also like to reiterate that I would like to support statically initialized TLS in terms of an API, but the ergonomics of doing so make it infeasible today in my personal opinion. Do note that it is entirely implemented in the sample implementation. API-wise, however providing two variants (dynamic/static) also seems somewhat overkill versus providing only one to worry about. I suspect with an extension to the macro syntax in the future (and ergonomic static initialization), we could tweak the macro to something like: `tls!(static FOO: Cell<uint> := Cell::new(3))` where here the `:=` means "statically initialized" and `Cell::new(3)` is evaluated at compile time.

I would also expect the number of candidates for a statically initialized TLS variable to be fairly small today. It's pretty rare to work with a data structure that can be statically initialized, so in practice if we provided 2 possibilities I would expect the dynamic variant's usage to far outweigh the static variant's usage. If, however, we see usage going in the other direction, we could certainly tweak the semantics!