Add method for reborrowing QueryData types

[ecoskey]

Objective

Allow reborrowing for QueryData types. The end goal here is to work towards a fast System::run_iter api, avoiding the overhead of get_param with each iteration. Funnily enough the only system param that actually needs this is Single, but it seems worthwhile to have anyways

Next steps:

1. SystemParam::reborrow
2. SystemIter

Solution

Add reborrow method to QueryData

[NicoZweifel]

This is pretty neat! This makes total sense to me in terms of utility functions and the like. I suggested a test that tests exactly this use case.

Other than that there are only a few minor things:

• For the EntityRef types, we can dereference and use the Copy implementations instead of manually creating the struct again, which is a bit more maintainable.

• The implemention of Ref<> can also be slightly simplified since ComponentTicksRef implements Clone.

• I noticed a few missing square brackets in the doc comments.

[chescock]

Oh, neat!

Add ReborrowQueryData, an optional subtrait (though almost all QueryData types should implement this in practice)

Do we have any QueryData types today that can't implement it? If not, then I would vote for putting the method directly on QueryData so that we don't need to add a new trait. We already require covariance through shrink(), so this wouldn't be that much more of a requirement.

• For the EntityRef types, we can dereference and use the Copy implementations instead of manually creating the struct again, which is a bit more maintainable.
• The implemention of Ref<> can also be slightly simplified since ComponentTicksRef implements Clone.

Could we make Ref: Copy, too? I don't see any reason why it can't be, and that would avoid needing a Ref::reborrow() method entirely. (I guess it has to be a manual impl instead of #[derive(Copy)] since we don't want a T: Copy bound on the impl.)

[alice-i-cecile]

I would prefer to get the System::run_iter change in at the same time as this work. It's hard to evaluate the utility of this change in isolation, and compile time / binary size costs mean that adding more methods to core traits like this is not free.

[ecoskey]

closing these for now, will wrap into a later PR if perf looks good

[NicoZweifel]

closing these for now, will wrap into a later PR if perf looks good

@ecoskey you can ping me if you want another review in a similar PR