Support for Intersection of multiple Sets at the same time

Currently the method intersection of HashSet and BTreeSet only support an intersection between two sets. If you want to intersect multiple sets, for example 3, you'll need to calculate the intersection between the first two, collect them into another set and calculate the intersection between that immediate result and the third set. This is very intense on computation, memory usage and lines of code.

I'd like to suggest the following:

1. Change the current implementations of the Intersection structs to contain a list of other sets to intersect with instead of a reference to a single other set. This applies to std::collections::btree_set::Intersection as well as std::collections::hash_set::Intersection.
2. Implement intersect_many (or intersect_multiple) on HashSet and BTreeSet which take a list of other sets to all intersect with the current one.
3. Add intersect and intersect_many (or intersect_multiple) to the Intersection structs as well. Those can only be called if the Intersection hasn't been iterated over yet. Otherwise, they'll panic.

If (3.) is implemented, the "list of sets to intersect with" will need to be a Vec in order to be growable after creation. For performance reasons, the third suggestion could be dropped and the "list" can instead be a reference to the provided slice.

The current implementation of {Hash,BTree}Set::intersection would need to be changed to pass &[other] instead of other.
While this request should be relatively easy to implement for HashSet (self.others.iter().all(|set| set.contains(elt)), implementing it for BTreeSet could result in a lot more code.

Unresolved Questions:

1. Naming: intersect_many vs intersect_multiple vs ???
2. Don't implement the third suggestion (functions on the Intersection struct) in favor of using an allocation free slice-reference instead of a Vec?

Start with the HashSet and BTreeSet intersection APIs and their Intersection structs described in the issue. Review the unresolved naming and allocation questions before proposing an RFC direction; done means the API design is agreed and the requested multi-set behavior is specified clearly enough for implementation.