Regression of the number of operations in the EOMs after CSE

[tjstienstra]

In the switch to using attachments in #103 a regression has been observed in the number of operations in the EOMs. For the default Whipple bicycle the following regression has been observed:

Implementation	Computation time $\mu \pm \sigma$ (s)	#Operations EOMs before CSE	#Operations EOMs after CSE
Manual by Moore	$3.5\pm0.2$	230789	2198
Manual by Stienstra	$6.6\pm0.3$	390554	2389
BRiM before #103	$5.8\pm0.3$	468290	2176
BRiM after #103	$7.3\pm0.8$	352210	2291

The table also shows some other implementations as a reference, which are also in the benchmarks/test_whipple_bicycle.py file. The first three results were specifically created over 50 runs on an Inter(R) Core(TM) i7-8750H CPU @ 2.20GHz with BRiM commit: ec02a0a. Note that the computation time does not matter too much and should be taken with a grain of salt, as the timing results differ more than the standard deviation from time to time.

I have tracked the change down to the fact that the usage of the rear_frame.steer_hub.to_valid_joint_arg() instead of rear_frame.body as parent argument in the steer joint results in the increase of operations after CSE. This means that the velocity graph of the points is defined a little differently. It is notable that the number of operations in the EOMs before CSE actually decreases.

In #103 I propose the following three solutions:

1. Upgrade the Point.vel method. While it would be ideal to make this more advanced, it is quite a nasty problem to solve.
2. Add an optimize_velocity_definition when exporting to a single System, which can later be moved to System within sympy. This is also not a simple solution, as one needs to detect when it is advantageous to compute a velocity using a certain theorem.
3. Add a manual set of velocity theorems in WhippleBicycle to optimize the velocity definition. This has the disadvantage of a constant labor.

When working on the third point I noticed that I was not able to get the wanted decrease when manually specifying the velocities which would be set by PinJoint when using rear_frame.body`. My hypothesis is that the automated velocity computation just follows a suboptimal path or multiple paths to compute the same velocity component. It would be optimal if everything always uses the same velocity component and not an alternative, but figuring out how to force this is quite a challenge.

This issue challenges us to find the exact reason for the seen regression and find an appropriate fix for it.

[tjstienstra]

It might be an idea to study the Point.vel warnings it gives on that a velocity can be computed w.r.t. different points. They seem to be different than before.

[tjstienstra]

This regression has been solved with the implementation of AuxiliaryDataHandler._compute_velocity in #128. The current number of operations in the EoMs before and after CSE is 266594 and 1908 respectively (2e7c89f).