Add API for task local data

[brson]

With task local data tasks can stash away a 'control port' in order to move linked failure and task notification into rust code.

See also #553

[brson]

pcwalton convinced me that we should be cautious about taking this step. For the task failure mechanism I am ok with giving libcore special privileges.

[catamorphism]

Should this be closed, then?

[brson]

I would like to leave it open a while longer. I haven't decided I don't want it.

[graydon]

I think we want it. It gives a mechanism for implementing lots of stuff in library code (in particular, the scoped error handlers and dynamic variables I've been thinking of adding).

The API I have in mind is pretty simple. It's a hashtable held off the side of a task. It's keyed by word-sized values (likely taken from the addresses of constants, which are conveniently unique per-process) and the values are (raw_ptr, crust_fn) pairs. The functions are finalizers. The raw pointers, we have no idea what they are. Likely unique boxes of our own choosing. The runtime finalizes the data when the task exits, otherwise user-code is responsible for any other structured get/put operations in this table.

This is an unsafe interface, would have to be used with care. Higher level conveniences (dynamic variables) would be built on top.

[graydon]

Note that it probably also makes sense not to push on it too heavily. I.e. probably keep a single "core::task control structure" as a single task-local value that covers all the needs of core::task and friends, not separately storing every individual field we need as separate task-locals.

[bblum]

Implemented. Currently in libcore/task.rs, may end up moving to libcore/tls.rs.