Query::get_multiple for accessing multiple entities simultaneously from the same query

[alice-i-cecile]

What problem does this solve or what need does it fill?

When working with queries, you sometimes need to access the data on multiple components at once. This is particularly frustrating if you require mutable access, due to Rust's borrow checking rules.

What solution would you like?

Add the Query::get_multiple(entities: HashSet<Entity>) -> HashMap<Entity, Result<[Elided](https://docs.rs/bevy/0.5.0/bevy/ecs/system/struct.Query.html#method.get_mut)>> method and the associated get_multiple_mut. By passing in a HashSet of entities, we can ensure that we never have mutable access to the entities at the same time.

Also add get_component analogues for this pattern.

What alternative(s) have you considered?

iter_combinations solves the common case, but other more bespoke access patterns certainly exist.

You can work around this by storing data, but that only works for Clone components.

@TheRawMeatball felt this should use a different API / impl:

it'd be more like a wrapper you put the query into
and then it'd pass out smart pointers wrappers of smart pointers

Additional context

#1470 may be easier to work around with this style of API.

It may make sense to use this implementation for iter_combinations in some way, but be mindful of perf as iter_combinations is likely to be used in tight loops for things like collision detection.

[alice-i-cecile]

Unsurprisingly, a parallel API for direct world access is probably a good idea too.

[alice-i-cecile]

rust-lang/rfcs#3100 treads similar ground, creating a trait for this style of functionality in the standard library. We could migrate this functionality to use that trait later once it's stabilized.

[alice-i-cecile]

Duplicate of #2042.

[burdges]

Just fyi, if you really really want access to multiple entries, then you might consider a cuckoo table. Those could've some index method which finds the positions for the key, and then you access those positions directly as if they were a Vec. Any write accesses could bump buckets contents of course, but only into a few other buckets, whic the index still locates. I've long meant to write a cuckoo table crate, because there are a bunch of really cool optimizations, but not yet done so.

[alice-i-cecile]

Really neat data structure! Would the main benefits be performance?

[burdges]

I'm unsure how performance works out, usually cuckoo filters wind up more memory efficent. I think few people use them because all the optimizations look more subtle than hash tables.

Afaik they work fine with the same good hashers and hash tables, like SipHash or HashBrown, but they're more sensitive to bad hashers, and some devs love plugging in bad hasher for speed.