Vec: add uninitialized(uint) and resize(&mut self, uint, T).

Add two more convenience methods to `Vec`.

Please review my English in the rustdoc comments!
> `--disable-jemalloc`

Good point.  You're right, reading data from uninitialized elements of a `Vec` under `--disable-jemalloc` is what LLVM define as UB.

Still, I don't think this is "more unsafe" than existing `unsafe` functions `Vec::from_raw_parts()` and `set_len()` which are already so flexible that anything can happen from their incorrect usage.  So the discussion should focus on "will adding one more rewards us?"

My point is, allocating a buffer to pass its slice to `Reader`'s `read_*()` methods and alike is a frequent use case and the library should support it with options with varying degrees of safety.  Note that the length of a vector has to be set properly beforehand.  Then my `Vec::uninitialized()` constructor should be preferred over calling bare `set_len()`.  From a safety point of view, `Vec::from_elem()` is the best, but "extra" cost of clearing a buffer is sometimes undesirable.  A benchmark with a 16 GB buffer on 3 GHz Xeon machine:

```rust 
fn main() {
    const GB: uint = 1 << 30;
    const N: uint = 16 * GB;

    let mut v = if 1 < std::os::args().len() {
        let mut v = Vec::<u8>::with_capacity(N);
        unsafe { v.set_len(N); }
        v
    } else {
        Vec::<u8>::from_elem(N, 0)
    };

    println!("{}", std::io::stdin().read_at_least(N, v.as_mut_slice()));
}
```
```
$ time ./large_vec < /dev/zero
Ok(17179869184)
./large_vec < /dev/zero  4.99s user 11.52s system 99% cpu 16.529 total
$ time ./large_vec < /dev/zero x
Ok(17179869184)
./large_vec x < /dev/zero  0.00s user 9.14s system 99% cpu 9.157 total
```

Also remember, if someone makes a mistake of reading past the end of the region written by `read_*()`, it's just a bug regardless whether or not the rest of the buffer was zero-cleard beforehand in a well-defined way.  "Safety" and "well-defined behavior" don't substantially help here.  We shouldn't always need to pay the extra cost of clearing a buffer for the doubtful benefit from "safety" and "well-defined behavior".