std::num: Add uint::next_power_of_two_opt

Like next_power_of_two, but returns None on overflow.
std::vec: Fix hazards with uint overflows in unsafe code

Issue #8742

Add the method `.reserve_additional(n: uint)`: Check for overflow in
self.len() + n, and reserve that many elements (rounded up to next power
of two). Does nothing if self.len() + n < self.capacity() already.
std::vec: Add function vec::bytes::push_bytes

`push_bytes` is implemented with `ptr::copy_memory` here since this
function is intended to be used to implement `.push_str()` for str, so
we want to avoid the overhead.
std::str: Add bench tests for StrVector::connect() and for str::push_str
std::str: Fix overflow problems in unsafe code

See issue #8742
rt::io: Use vec::reserve_additional
std::at_vec: Fix segfault on overflow when resizing ~[@T]

Easy to reproduce:

    let mut v = ~[@1];
    v.resize(-1);  // success a.k.a silent failure
    v.push(@2); // segfault
auto merge of #9108 : blake2-ppc/rust/hazards-on-overflow, r=alexcrichton

Fix uint overflow bugs in std::{at_vec, vec, str}

Closes #8742

Fix issue #8742, which summarized is: unsafe code in vec and str did assume
that a reservation for `X + Y` elements always succeeded, and didn't overflow.

Introduce the method `Vec::reserve_additional(n)` to make it easy to check for
overflow in `Vec::push` and `Vec::push_all`.

In std::str, simplify and remove a lot of the unsafe code and use `push_str`
instead. With improvements to `.push_str` and the new function
`vec::bytes::push_bytes`, it looks like this change has either no or positive
impact on performance.

I believe there are many places still where `v.reserve(A + B)` still can overflow.
This by itself is not an issue unless followed by (unsafe) code that steps aside
boundary checks.