Deprecate unsafe functions in `str::raw` and `OwnedStr` trait

### Removed the `OwnedStr` trait

This trait was only implemented by `String`. It provided the methods `into_bytes` and `append`, both of which **are already implemented as normal methods** of `String` (they where duplicated). This change improves the consistency of strings.

Its removal shouldn't break any code, except if somebody has implemented `OwnedStr` for his own types.

### Deprecated some unsafe functions

* `from_c_str` in favor of `String::from_c_str`
* `from_utf8_owned` in favor of `String::from_bytes` (we could give it another name if you have a better one)
* `from_byte` in favor of `String::from_bytes` (make a new vector with a single byte and call the function)

### Questions

I would like to deprecate `from_buf_len` as well. This way we would get rid of `str::raw` completely.

After thinking about it, it seems to me that `from_buf_len` addresses a problem that is not related to strings. What the user really wants is to build a `String` from a slice (or vector) of bytes. This can be done by calling `String::from_bytes` (without checking for UTF-8-ness) or `String::from_utf8` (checking). However, there is no easy way to convert a pointer to a slice, so we need a special function. I think the real solution would be to add a new method to the `RawPtr` trait. Something like:

```
// I don't know if this would compile. It is just an example
unsafe fn as_slice<'a>(&'a self, len: uint) -> &'a [T] {
    mem::transmute(Slice {
        data: self, // Self is a *const T
        len: len,
    })
}
```

If we had this function, then we would be able to deprecate `from_buf_len` in favor of `String::from_bytes(buf.as_slice(len).to_vec())`, which seems much better to me. Otherwise we can just keep this function and move it to the `string` module.

Do you think this is a good idea? Should I submit a new PR for this or just add it here?

[breaking-change]