RFC: Raw Reform

* Introduce RawSlice and RawMutSlice extension traits to be implemented on
`*const [T]` and `*mut [T]` that provide parts of the slice and ptr API to better bridge the
gap between the two.

* Provide unsafe versions of the slicing and indexing operators on raw slices to provide ergonomic
unchecked slice manipulation.

* Provide unsafe versions of the addition, subtraction, and indexing operators on raw ptrs to
provide more ergonomic ptr manipulation.

* Deprecate some of the free functions in `ptr`, and duplicate the rest as convenience methods on
the RawPtr extension traits.

* Deprecate *all* `unsafe` methods on slices and `slice::raw` in favour of raw slices.

* Add conversion methods to the three families of extension traits for conveniently moving between
them.

[Rendered](https://github.com/Gankro/rfcs/blob/raw-reform/active/0000-raw-reform.md)
>When porting code to Rust, you may modify types along the way, and that would potentially invalidate any pointer arithmetic. For example, if you took C code that used int and converted it to Rust code that used int, the size of the type is now different on 64-bit machines.

If you pointer arithmetic depends on the size of a certain type, then choosing a different size when porting is a bug unrelated to pointer arithmetic. In this case the issues and RFCs related to the name of Rust's int type are more relevant. Either way, if
```rust
(x + 1) as uint == x as uint + size_of::<X>()
```
then a faithful port will have the same way. Furthermore, pointer arithmetic will be used much more often for the inspection of arrays, and in this case only the number of elements matters, and not the contained type.

>I actually think it's slightly easier to read, because it highlights the fact that this is pointer arithmetic

This has nothing to do with readability but [something whose name I don't know]. Given full knowledge of the behavior of the operations involved,
```rust
x + y
```
is more readable than
```rust
x.add_with_possible_overflow(y).
```
In this case, x and y are integers. And while integer arithmetic is more frequent than pointer arithmetic in Rust code, when you port code, you want to change as little as possible in order to not introduce new bugs. 

Secondly, I do not believe that the behavior of pointer arithmetic is a source of many bugs (compared to ordinary unchecked array indexing.) Most of the time you either index an array or inspect an object with c_char pointers (also because of the stricter aliasing rules in C.) In the second case, pointer arithmetic behaves just like integer arithmetic. 

Thirdly, pointer arithmetic only happens in unsafe blocks where increased attention is required anyway.

Lastly, raw pointers are not arbitrary memory locations but the addresses of properly aligned objects. Nobody would expect `x + 1` to create a pointer whose address is one larger than the address of the previous pointer, because that would be undefined behavior if the required alignment for `*x` is larger than one.