Added partition_map_multiple

[jeroenvervaeke]

Issue

partition_map enables you to split an iterator into 2 separate collections. You can choose if you want to put the current item into the Left collection by returning Either::Left or put it in the Right collection by returning Either::Right.
The limitation of partition_map is that you can only put the result in the Left or the Right collection, but not in both.

Practical example

I have some kind of batch processing pipeline that has a list of tuples.
The definition of these tuples looks like this: (Uuid, Vec<Result<Ok, Error>>).
I want to split this iterator of tuples into 2 vecs (or hashmaps) of tuples: (Uuid, Vec<Ok>) and (Uuid, Vec<Err>).

This is where partition_map_multiple comes in.
If the tuple contains no errors I return EitherOrBoth::Left, in case the tuple contains no oks I return EitherOrBoth::Right, in case my tuple contains both errors and oks I return EitherOrBoth::Both.

Remarks

• I used this extension quiet a lot in a batch processing application I wrote. I'm not sure if this extension fits into this crate, all feedback is welcome.
• I did not alter the partition_map function to avoid breakage

[phimuemue]

I see that this may have some value. However, if we decide to accept it (probably @jswrenn's call), I'd vote to investigate if we could generalize this to not only support EitherOrBoth, but also tuples, such as (Option<A>, Option<B>, Option<C>) - which would then collect the Somes into three respective containers.

I think it is feasible to implement it (probably up to the maximum number of tuple elements that we use in other places, too): See here for a draft. We could use macros to generate the tuple implementations, and possibly even express the EitherOrBoth-version in terms of the (Option, Option)-version.