Idea for deserialization flexibility

[fasterthanlime]

I have a little conundrum right now, I need to deserialize a field named draft-code, and I really don't want to name a field r#draft-code (I'm not even sure what the stringify result of that would be) — between that and deny_unknown_fields that cannot be turned off, also fields that cannot be made optional... I was thinking about how deserialization could be made more flexible.

And I kinda like the idea of the Deserialize trait's main function taking some sort of "Context" or "Opts" structure that could do things like:

• Turn on deny_unknown_fields
• Given a key, decide if a field is required, or if we should use its default value (that one's kind of annoying because ideally we'd want more flexibility, ie. to return a T rather than say "use the default" — we cannot return a T but we might be able to fill in an &mut Option<T> but.. how do we guarantee type safety in this case? some kind of downcasting would be needed)
• Map a key name to another key name — when deserializing structs, if we encounter draft-code, that function could map it to draft_code. This can be done as a CowStr<'s> -> CowStr<'s> — and then it would work the same for structs and HashMaps.

This approach would avoid combinatory explosions of macro_rules — which are already pretty bad right now — and could push the boundaries in terms of flexibility, without having to resort to codegen (yet!). I also think they wouldn't necessarily be a big problem performance-wise.

[fasterthanlime]

Done in #89