Fix send() charset overriding to use new MIME type infrastructure

[domenic]

This is a known issue but I don't see a tracking bug. Basically,

Otherwise, if the header whose name is a byte-case-insensitive match for Content-Type in author request headers has a value that is a valid MIME type, which has a charset parameter whose value is not a byte-case-insensitive match for encoding, and encoding is not null, then set all the charset parameters whose value is not a byte-case-insensitive match for encoding of that header’s value to encoding.

should be done in terms of MIME Type parsing and serialization.

I'm especially wondering what to do if parsing fails.

[domenic]

https://github.com/w3c/web-platform-tests/blob/master/xhr/send-content-type-charset.htm will need to be updated when this gets fixed; it currently assumes that multiple parameters with the same name ("charset") will survive a roundtrip.

[annevk]

This is #176. It has tests too, but nobody is reviewing.