Add `Deserializer::deserialize_iter` for convenience

[cactusdualcore]

It's like deserialize_seq, but lazily evaluated!

I think deserialize_seq is annoying. Every single collection needs its own visitor, but most collections already implement a (probably even optimized!) FromIter implementation or similar.

Whenever visit_seq is used, there already is a Iterator of some sort. Any type implementing SeqAccess behaves effectively like one. As far as I can tell, the only difference is that SeqAccess allows for passing in seeds during iteration.

In essence, this hypothetical deserialize_iter method could share most machinery with the sequence deserialization, except it gives control back up the call stack.

This would significantly reduce the pain of writing custom deserialization for types with sequence fields.

#[derive(Deserialize)]
struct Bar;

struct Foo(Vec<Bar>);

impl<'de> Deserialize<'de> for Foo {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>
    {
        let bars = deserializer
          .deserialize_iter::<Bar>()
          .collect::<Result<_, _>>()?;
        Ok(Foo(bars))
    }
}

[cactusdualcore]

Rust as a language is much more streamlined for aggregating existing fields rather than backfilling empty templates.

I am aware that visitors and backfilling allow for heterogenous types to be easily deserialized, which is not trivial otherwise (as far as I can tell).

For almost anything else, though, I think a top down approach simplifies hand-written code greatly.