Implement serialization of tuple variants of flatten enums

[Mingun]

Actually, I investigating a way of possible fixes of #1183, during which I try to narrow frontier of work as much as possible. I investigating an idea of using configurable buffer instead of generic Content. During that I found that generalizing of this type requires some knowledge of the Content internals -- VariantDeserializer::tuple_variant and VariantDeserializer::struct_variant does the matching over Contents content:

serde/serde/src/private/de.rs

Lines 1553 to 1557 in 25381be

	match self.value {
	Some(Content::Seq(v)) => {
	de::Deserializer::deserialize_any(SeqDeserializer::new(v), visitor)
	}
	Some(other) => Err(de::Error::invalid_type(

serde/serde/src/private/de.rs

Lines 1576 to 1583 in 25381be

	match self.value {
	Some(Content::Map(v)) => {
	de::Deserializer::deserialize_any(MapDeserializer::new(v), visitor)
	}
	Some(Content::Seq(v)) => {
	de::Deserializer::deserialize_any(SeqDeserializer::new(v), visitor)
	}
	Some(other) => Err(de::Error::invalid_type(

Here I noticed, that MapDeserializer and SeqDeserializer are different structs from the common de::value module. At first glance the difference is cosmetic, so I tried to remove custom implementations and use counterparts from de::value. The last commit of this PR does that and actually that was the commit that I want to PR.

Because this change could have non-obvious consequences, I tried to find tests that reaches changed code paths. During that I found that for some of them there are no tests, so I write them.

However, in the process of writing tests, it turned out that deserialization of the enum tuple variant from sequence is supported, but such an enumeration cannot be serialized. So in the end I implemented that and close the gap.

When writing tests, I tried to organize them hierarchically, because in the current approach it is completely incomprehensible which parts are tested and which are not. Tests piled into a heap without any system. I found, that organizing tests using built-in capabilities of Rust -- modules -- greatly improves readability of tests and understanding of what is tested. Because tests in this PR not the main thing on which I focus, you can find that organizing of them are slightly incomplete. That is true. I plan to clean them up in the following PRs.

[dtolnay]

Thanks!

I appreciate the detour into improving the tests.