Force Rework

[Jondolf]

A bit over a week ago on the Discord, I mentioned wanting to make the force and impulse components not required. This is still true, but I've been thinking that the force API might also be sorely in need of a rework in general.

• The "persistent" vs. "not persistent" force split is confusing. You can't even apply both at the same time.
• Why do impulses (intended to be "instantaneous") use components, and why do they support persistence?
• The coordinate spaces are confusing and implicit, and applying local forces or torque (especially persistently) is a pain.
• Keeping forces and torque in separate components means that ExternalForce also needs to store a torque, just because of apply_force_at_point.

I'm still in the brainstorming phase, but I was thinking that we probably want a way to just call apply_force, apply_local_force, apply_linear_impulse, and so on without having to mess with components in the API. One idea I was playing around with is a ForceHelper system param:

fn orbit(query: Query<Entity, With<Planet>>, mut forces: ForceHelper) {
    for planet in &query {
        // ...compute gravity force...
        forces.entity(planet)
            .apply_force(gravity_force)
            .apply_local_torque(spin_torque);
    }
}

Internally, it can use components, commands, or whatever makes the most sense for a given method. I think this is a pretty nice and flexible approach, and perhaps closer to how you'd actually expect the force API to work. External forces and impulses are primarily an API abstraction for modifying velocity, not "a thing" a rigid body inherently has, so I think a system param approach makes sense.

In terms of the existing components, I think I would:

1. Remove ExternalImpulse and ExternalAngularImpulse in favor of just making ForceHelper able to apply instantaneous impulses.
2. Store forces and torque in the same component. This component could also store local forces and torque separately from world-space values.
3. Instead of the persistent property, we could have a separate ConstantForce or PersistentForce component. This would live in table storage, while the non-persistent version would be a SparseSet component that gets inserted whenever forces are applied, and removed when it is zero at the end of a physics timestep.