implement FromEntitySetIterator

[Victoronz]

Objective

Some collections are more efficient to construct when we know that every element is unique in advance.
We have EntitySetIterators from #16547, but currently no API to safely make use of them this way.

Solution

Add FromEntitySetIterator as a subtrait to FromIterator, and implement it for the EntityHashSet/hashbrown::HashSet types.
To match the normal FromIterator, we also add a EntitySetIterator::collect_set method.
It'd be better if these methods could shadow from_iter and collect completely, but rust-lang/rust#89151 is needed for that.

While currently only HashSets implement this trait, future UniqueEntityVec/UniqueEntitySlice functionality comes with more implementors.

Because HashMaps are collected from tuples instead of singular types, implementing this same optimization for them is more complex, and has to be done separately.

Showcase

This is basically a free speedup for collecting EntityHashSets!

pub fn collect_milk_dippers(dippers: Query<Entity, (With<Milk>, With<Cookies>)>) {
    dippers.iter().collect_set::<EntityHashSet>();
    // or
    EntityHashSet::from_entity_set_iter(dippers);
}

[SpecificProtagonist]

Hmm… this is slower for me:

let mut world = World::new();
for _ in 0..1_000_000 {
    world.spawn_empty();
}
let mut query = world.query::<Entity>();
for _ in 0..10 {
    query.iter(&world).collect::<EntityHashSet>();
}

gives me

  Time (mean ± σ):      81.1 ms ±   0.9 ms    [User: 56.1 ms, System: 24.5 ms]
  Range (min … max):    80.0 ms …  83.7 ms    36 runs

while doing the same with collect_set gives

  Time (mean ± σ):     221.8 ms ±   4.3 ms    [User: 108.1 ms, System: 112.2 ms]
  Range (min … max):   217.2 ms … 231.5 ms    13 runs

This seems to be because it doesn't use size_hint. With that fixed it improves to

  Time (mean ± σ):      79.1 ms ±   2.3 ms    [User: 54.8 ms, System: 23.9 ms]
  Range (min … max):    77.7 ms …  92.1 ms    37 runs

or slightly faster than the standard collect (the spawning part of this benchmark takes about 26ms, with this PR improving the iter/collect part from ~49ms to ~47ms). Not a huge difference :/

[Victoronz]

good catch!
I was going to perf test it after to check, but it does seem to be a rather small gain :P
Judging from indexmap-rs/indexmap#200, it seems the return type in the implementation does make this somewhat slower than it could be, but it is still an improvement nonetheless.

[Victoronz]

slightly faster than the standard collect (the spawning part of this benchmark takes about 26ms, with this PR improving the iter/collect part from ~49ms to ~47ms). Not a huge difference :/

What system/compilation settings did you use to bench this?

[Victoronz]

I've also changed the for loop into a fold, since internal iteration is known to generate bit better code.
Might not/probably does not have an impact for simple/common iterators though.