Add std derives to SystemParam types

[spectria-limina]

Objective

• Use Clone on SystemParam, when applicable, in a generic context.

Solution

• Add some derives

Testing

• I ran cargo test once.
• I didn't even look at the output.

[alice-i-cecile]

Why Copy here?

[alice-i-cecile]

It would be helpful to reviewers to briefly explain why Clone was needed on these types.

[BD103]

I'm fine with the code changes themselves, but some justification would be appreciated! :)

[BenjaminBrienen]

If it were just Clone, that would be easier to approve. Why Copy?

[spectria-limina]

Sorry for the delay replying.

Types should eagerly implement applicable traits.

My use case was playing around with some dynamic manipulation of builders in order to inject data into a system during state initialization, and my test usage with Local required cloning the builder so that the same builder could be mapped to multiple arguments of a system.

So I think the question is better asked as: why not?

Builder types are only used in the guts of

As for Copy, I think I actually should have made more of them Copy. I don't really see any reason why these shouldn't be Copy when wrapping a Copy type. And [therefore it should] (https://doc.rust-lang.org/std/marker/trait.Copy.html#when-should-my-type-be-copy).

Note that for actual SystemParams, I think Clone or especially Copy wouldn't work because the semantics are tied to the system and it's state. But this is just the builders, and they are basically fancy named closures.

[mockersf]

So I think the question is better asked as: why not?

More derives mean more build time

And [therefore it should] (https://doc.rust-lang.org/std/marker/trait.Copy.html#when-should-my-type-be-copy).

A lot of people think this advice is wrong. Deriving Copy change the usage of a type from move semantics to copy semantics, and can lead to unexpected behaviour