Fix remaining documentation to reflect fail!() -> panic!()

Throughout the docs, "failure" was replaced with "panics" if it means a
task panic. Otherwise, it remained as is, or changed to "errors" to
clearly differentiate it from a task panic.
Fix documentation bug

The first paragraph must be separated from the next paragraph.
Otherwise, rustdoc will consider the content of the latter as part of
the title.
librustc: Allow linkage attribute on any statics, not just foreign statics.
librustc: Respect no-compiler-rt target option for static libs as well.
Results aren't panics

A typo about Results being panics crawled in. Fixing it.
Fix po4a.conf
fix "warning: deprecated syntax, use `for` keyword now"
Reference: Fix list in Expressions section
convert 1 line match to 2 lines for readability
Don't use rust  keyword for fake code
src/etc/snapshot: support triples lacking a vendor
Make std::io::Buffer object-safe.

[breaking-change]
Any uses of Buffer::lines() and Buffer::chars() will need to use the new trait std::io::BufferPrelude.
Remove BTreeSet from all examples.
Rewrite std::sync::TaskPool to be load balancing and panic-resistant

The previous implementation was very likely to cause panics during
unwinding through this process:

- child panics, drops its receiver
- taskpool comes back around and sends another job over to that child
- the child receiver has hung up, so the taskpool panics on send
- during unwinding, the taskpool attempts to send a quit message to
  the child, causing a panic during unwinding
- panic during unwinding causes a process abort

This meant that TaskPool upgraded any child panic to a full process
abort. This came up in Iron when it caused crashes in long-running
servers.

This implementation uses a single channel to communicate between
spawned tasks and the TaskPool, which significantly reduces the complexity
of the implementation and cuts down on allocation. The TaskPool uses
the channel as a single-producer-multiple-consumer queue.

Additionally, through the use of send_opt and recv_opt instead of
send and recv, this TaskPool is robust on the face of child panics,
both before, during, and after the TaskPool itself is dropped.

Due to the TaskPool no longer using an `init_fn_factory`, this is a

[breaking-change]

otherwise, the API has not changed.

If you used `init_fn_factory` in your code, and this change breaks for
you, you can instead use an `AtomicUint` counter and a channel to
move information into child tasks.
serialize: Add ToJson impl for str
Expand the benchmarking and unit test suite for ring_buf.
-Adds unit tests for fn get() and fn get_mut() which are currently untested
-Adds unit tests to verify growth of the ringbuffer when reserve is called.
-Adds unit tests to confirm that dropping of items is correct
Move ringbuf to use a raw buffer instead of Option<T>
Handle allocate/reallocate errors in ring_buf
Use is_some() in clear to simplify the clear loop.
Added some extra debug_asserts to ring_buf.
Manually reset the ringbuffer before or after the ringbuffer push/pop tests.
Added population count assertion in reserve. Cleaned up wrap_index.