Velocity calculation update

[Copper280z]

Use time between encoder ticks to better estimate low speeds. Calculate an upper bound on velocity based on encoder resolution and time since last tick and use that to update the current velocity estimate when no ticks are observed.

This change improves stability of conditional effects, specifically the damper an inertia, when set at high values.

Once this is merged, I would recommend removing the encoder speed filter entirely, it's no longer necessary, and increasing the cutoff frequency for the accel filter. Additionally, implementing either persistent storage for the encoder resolution, or implementing the getCpr function such that it returns the real encoder resolution instead of 65535 will improve the velocity estimate.

Right now, without a working getCpr or persistent storage for the encoder resolution, I have the value hard coded. Basically any value here is still an improvement over the prior method, even '1', but the correct value will further increase the accuracy of the estimate.

This same method could also be applied to the acceleration calc, which should improve inertia stability and smoothness even more.

[Ultrawipf]

Sounds like a good idea.
The getCpr returns the resolution depending on the encoder. Only on the tmc4671 it is currently not the case because it uses the already scaled counter at the moment.
This could be changed but then requires special handling for every combination again.

Please check out the ultrawipf/testing branch which contains upcoming changes not yet merged to development like dynamic sample rates which would affect this calculation.

[Copper280z]

The odrive and vesc motor drivers also do not return the actual cpr.