Issue title: fold_map_collect
 Issue body: Would something like a `fold_map_collect` be of interest for inclusion into itertools?

```rust
trait IteratorExt: Iterator {
    fn fold_map_collect<C, B, M, F>(self, init: B, mut f: F) -> (B, C)
    where
        F: FnMut(B, Sel38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Item) -> (B, M),
        C: Default + Extend<M>,
        Self: Sized,
    {
        let mut c = <C as Default>38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5ult();
        let mut init = init;
        match self.size_hint() {
            (_, Some(upper)) => c.extend_reserve(upper),
            (lower, None) => c.extend_reserve(lower),
        }
        for item in self {
            let (new_init, mapped) = f(init, item);
            init = new_init;
            c.extend_one(mapped);
        }
        (init, c)
    }
}

impl<T: Iterator> IteratorExt for T {}
```

Example usage:

```rust
let (width, grid) =
    st38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5io38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5stdin()
        .lock()
        .lines()
        .fold_map_collect(0usize, |max_width, line| {
            let (line_width, line) = line.unwrap().chars().enumerate().fold(
                (0usize, 0u64), // (character count, encoded line)
                |(count, line), (idx, chr)| {
                    (
                        count + 1,
                        match chr {
                            '.' => line,
                            '#' => line | (1u64 << idx),
                            _ => panic!("invalid grid line"),
                        },
                    )
                },
            );
            (cmp38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5max(line_width, max_width), line)
        });
```

The name is bikesheddable.
 Comments: 
 Comment 0: My default instinct here is that combining this many different things is the wrong way to go.

This gives me a big of a `scan` vibe?  Is there a way to make an additional accessor on that?  Or a different kind of adapter that doesn't need to include the `collect` stuff too?
 Comment 1: > This gives me a big of a scan vibe? Is there a way to make an additional accessor on that?

You mean something like `scanl 38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5 (a -> b -> a) -> a -> [b] -> [a]`? That wouldn't work because I need both the accumulator *and* mapped items returned. Both types might differ so it also not possible to just add the accumulator into the returned list.

> Or a different kind of adapter that doesn't need to include the collect stuff too?

I have though about this but can't find a way because fold and map are quite “different” in terms of execution (lazy and eager evaluation. This pattern requires eager evaluation though).`std` does include `unzip` but using that isn't "zero-cost" (because then I'd have to store the fold values for each entry and then stored them in a container, followed by the operation i want to do, eg. `max`).

I mean another thing you can do is just introduce a local and update the local each time you are trying to do your fold computation. But perhaps this is the more elegant solution to do this? (That would be unsatisfying.)
 Comment 2: Can't you just use an external variable with `map` and `collect`?

```rust
let mut max_width = 0usize;
let grid =
    st38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5io38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5stdin()
        .lock()
        .lines()
        .map(|line| {
            let (line_width, line) = line.unwrap().chars().enumerate().fold(
                (0usize, 0u64), // (character count, encoded line)
                |(count, line), (idx, chr)| {
                    (
                        count + 1,
                        match chr {
                            '.' => line,
                            '#' => line | (1u64 << idx),
                            _ => panic!("invalid grid line"),
                        },
                    )
                },
            );
            max_width = cmp38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5max(line_width, max_width);
            line
        })
        .collect();
```
 Comment 3: @SkiFire13 Well, yeh that would be possible, but I thought it would be nice to avoid state mutation ala Iterator38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5old, but I guess this is such a niche case, it’d be much more readable with state mutation.
{'source': 'GithubIssues', 'repo_name_with_owner': 'rust-itertools/itertools', 'issue_id': 756371004, 'repo_stars': 1864.0}