Splitting serialization2 into a serializer and deserializer trait

[erickt]

Some types don't make sense to deserialize, such as &str types. This patch moves deserialize out of Serializable into it's own trait, and adds support for the following types:

char
&str
@str
&[T]
@[T]

It also adds an explicit emit_struct and read_struct that passes along the struct name to the Serializer/Deserializer.

It doesn't yet include the "pass-the-serializer-in-a-a-trait-typarm" that @nikomatsakis and I were talking about in IRC, as that seems to trip over an ICE.

It also includes a small patch that renames vec::raw::from_slice into vec::raw::buf_as_slice, which matches str::raw::buf_as_slice and a small bit of cleanup.

[brson]

@nikomatsakis Can you review this?

[nikomatsakis]

My impresions: this code looks good, though I think it'd be best if (eventually, perhaps not as part of this pull request) #[auto_serialize] were divided into two annotations: #[auto_serialize] and #[auto_deserialize].

[erickt]

I just realized there's a bug. Auto-deserializing a struct still uses d.emit_rec instead of d.emit_struct. I'll upload a fix in a couple minutes. I like #[auto_deserialize], I'll look into it too.

[nikomatsakis]

OK. I tried rebasing this onto incoming and got some merge conflicts.
Didn't look like anything terribly significant. But if you're improving
the patch, I'll hold off on merging it down.

[erickt]

Added in my fix, and prepped (but haven't finished yet) support for #[auto_deserialize].

[nikomatsakis]

I'll look at this.

[erickt]

Updated to add #[auto_deserialize] and other misc bug fixes.

[nikomatsakis]

Thanks.