Adopt a Fetch pattern for SystemParams

[cart]

Resolves #1032

Unfortunately the SystemParam approach currently used on master suffers from a safety hole. You can annotate system parameters like Res<'static, X> and suddenly we have a static pointer to a non-static resource! Thats bad!

To resolve this, I have adopted a "Fetch" pattern for SystemParams (the pattern used by WorldQueries).

This accomplishes two things:

• Makes it impossible to convert a function with static references to a system
• Removes the need to hack lifetimes inside of SystemParams, making the implementation much safer.

There is one major downside to this approach. We can no longer use this syntax:

app.add_system(movement)

Instead we must go back to doing this:

app.add_system(movement.system())

Yeah yeah ... I'm not happy about it either. But safety comes first. I'm hoping we find a magic implementation with no compromises, but until then something needs to give. And it can't be safety!

I encourage anyone interested to play around with the "minimal" examples in the link above. Maybe you can discover an ideal implementation.

[mockersf]

calling a function on a function (my_system_function.system()) was one of the strange and surprising part of the API.

could we have a macro system!(my_system_function) that would do it for us? It doesn't change anything but I feel it would make the API easier to grasp

[cart]

calling a function on a function (my_system_function.system()) was one of the strange and surprising part of the API.

could we have a macro system!(my_system_function) that would do it for us? It doesn't change anything but I feel it would make the API easier to grasp

I'm pretty firmly anti-macro in that case. "no macros in the public ecs api" is one of my favorite parts of bevy, and is one of the things that distinguishes us from the other options out there.

[J-F-Liu]

I also like the neat app.add_system(movement), after reading the code still can't understand why this is no longer possible.