std: Add a new top-level thread_local module

[alexcrichton]

This commit removes the std::local_data module in favor of a new std::thread_local
module providing thread local storage. The module provides two variants of TLS:
one which owns its contents and one which is based on scoped references. Each
implementation has pros and cons listed in the documentation.

Both flavors have accessors through a function called with which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of RFC 461 and full details can be found in
that RFC.

This is a breaking change due to the removal of the std::local_data module.
All users can migrate to the new tls system like so:

thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None)))

The old local_data module inherently contained the Rc<RefCell<Option<T>>> as
an implementation detail which must now be explicitly stated by users.

[breaking-change]

[rust-highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[alexcrichton]

cc @aturon, @nikomatsakis, you may be interested in the API decisions here (everything panics)

[oli-obk]

I find "tls" to be a little ambiguous as a name, since it's already much in use for transport layer security.
Searching for problems will be quite troublesome, as the two need to be kept apart

[seanmonstar]

You ordered this alphabetically, except for tls.

[alexcrichton]

Sadly this is due to how macros work, some of the modules below need the tls macro which requires it to be defined first.

[frewsxcv]

I'd also vote against utilizing the acronym tls, seems like it will only cause confusion, despite appearing attractively concise

[aturon]

I wonder if it's worth providing a newtype abstraction around RefCell<Option<T>> with a flattenend API; seems to come up from time to time.

[aturon]

OK, I've read over the entire implementation, pretty carefully. Great work!

I'm happy with the panic semantics here.

I agree with what others have mentioned about tls being a bit problematic, as we discussed on IRC. I don't care much what it's changed to (tld would be fine by me).

The module organization here strongly implies that the owned variant is the primary/default one, which is probably true, but we may want to revisit that before final stabilization.

Other than the tls naming issue, r=me

[alexcrichton]

I've renamed every mention of "tls" to "thread_local"

[seanmonstar]

Is there a way forward for the liblog to copy or share the logger with child tasks with this design?

[alexcrichton]

@seanmonstar probably not, but that's more of a problem for liblog than the inherent design of this module itself. The purpose of this module is to expose the system primitives available with a safe interface.