Add global data API, rewrite chan_from_global_ptr

[brson]

It would be similar to the local data API, except that values are probably RWARCs for mutable data and ARCs for immutablel data.

Then chan_from_global_ptr could be expressed in terms of the global data API, storing a pipe-based channel, which would get it away from using core::comm.

linenoise also needs a global mutex, which this would provide.

There's some question about where the constructor runs, but the API could just hand you a RWARC<Option<T>> and let you figure it out - presumably anybody using this API would encapsulate it in something else. The hard part is deciding when to do the cleanup and whether to allow destructors. The obvious thing I can think of is to have a weak task do it, and weak tasks have to know not to rely on global data during shutdown.

Like the local data API it would be unsafe until we have a good way to name the key.

Related to #553

[brson]

getenv/setenv could also just use the RWARC's as mutexes and not create an entire task

[Blub]

Would that mean all globals are *ARCs? Or would I be able to make "normal" globals, too. Because more often than not I want to avoid the overhead of an ARC.
Personally I also wouldn't mind "uninitialized" globals - there could be unsafe builtin to set a variable without caring about its previous contents. (So that you can initialize a global @ptr without it trying to deallocate the previous (invalid) data. (Or they they could live in the data section with their reference count initialized to 2 or something, but that wouldn't solve the issue for ~ptrs)

[brson]

@Blub, this API is intended to be safe, so ARCs make the most sense to me. There is another proposal for adding unsafe globals to the language: #553.

Plain ARCs though have, in theory, no overhead to read, while RWARCs do involve locking.

Also, global @-pointers would be very unsafe.

[Blub]

I don't think global @-pointers are required, but ARCs are read-only, and RWARCs add overhead, this is my main concern. I think this and #553 should go hand in hand: mut-globals which are declared as unsafe should not be RWARC-guarded. I'd really like to use mutable globals, but I would definitely not use RWARCs in my current usecases.

[brson]

Rewriting chan_from_global_ptr also requires rewriting weaken_task since the use of the two of them together necessitates selecting on two ports, and those two ports must be the same sort of port.

[catamorphism]

@brson Still relevant?

[brson]

This is done.