Selective JSON deserialization

[robertbastian]

I think it's time to relegate JSON serialization to what it really is: useful for inspecting data during debugging. However, the more readable we make the JSON, the harder it gets to parse. We already have a serde_human feature in some crate to have a more readable human representation, but I don't think that feature is worth its weight (it pulls in dependencies).

I'm currently splitting a ZeroMap into a ZeroTrie and a list, which makes the JSON completely unreadable. If we didn't have to deserialize it, I could serialize it in a nicer way, all behind the datagen feature.

[sffc]

A few points:

• As others have pointed out, we shouldn't use Serde's is_human_readable flag to determine whether a target serialization format can be deserialized or not. It is possible that we could make our own special serializer and sniff for it using the TypeId. I would be okay with such a solution, and it doesn't even need to be JSON.
• Longer-term, a polymorphic zeromap / karte crate (Improve map polymorphism #3128) solves some of these issues, although not all of them, like the pre-existing list formatter data.
• In the short term, I would approve a PR with a // TODO comment in the is_human_readable() Deserialize impl pointing to an open issue. It should be designed in a way such that the impl could be written, and for now it can return a deserialization error.

The last bullet is consistent with the notion that human-readable deserialization is supported but only on a best-effort basis.