std::str: stop from_utf8 allocating.

[huonw]

This function had type &[u8] -> ~str, i.e. it allocates a string
internally, even though the non-allocating version that take &[u8] ->
&str and ~[u8] -> ~str are all that is necessary in most circumstances.

[chris-morgan]

So, to maintain the same semantics—where what from_utf8 did actually was what was intended—one will need to change str::from_utf8(slice) to str::from_utf8_owned(slice.to_owned()), which looks like it should be comparable in efficiency.

In cases where auto-slicing was employed (i.e. where the argument was actually ~[u8] rather than &[u8]), either pass it directly to str::from_utf8_owned or clone it before passing it in, as desired.

[alexcrichton]

I'm a little concerned about this, on one hand it seems unfortunate that we're making this fairly common api more difficult to use, but on the other hand I like how this is much more explicit about storage needs.

It'd be awesome if we had the same storage benefits from using only str::from_utf8, but I'm not sure if that's possible. Regardless, I'd like this to have some more discussion before merging.

[huonw]

By more difficult to use you mean "one has to work out if one wants a ~str or &str" rather than just letting the library hand you a ~str always?

FWIW, I think it's not that bad, as one can see from this change just using from_utf8_owned and/or from_utf8_slice is a drop in replacement in most situations, with from_utf8_owned(....to_owned()) mostly only necessary due to other bugs (specifically, extra::json using @mut Writer everywhere, so one can't move out of the @mut MemWriter).

[huonw]

I just added a commit that renames what was from_utf8_slice into from_utf8, so this PR now has the effect of making from_utf8 be &[u8] -> &str and removing from_utf8_slice. (I'm happy to remove/amend that commit if that's deemed suboptimal/has a better suggestion.)