Feature/RPM + sensor thresholds + fancy sensors

[Apehaenger]

Like to see "normal" RPMs.
Mainly for the mower-motor because this is the one of interest... but for sure, as we've a common code-base for all ESC's, it will be published also for the drive ESCs.

State of ESCs:

• Rev4-Adapter has real RPMs as it's only an "intelligent switch". FW-Code is ready and in dev branch. Get merged to main once ros part got merged... however, nobody cares, as only one person use it (I'll inform him)
• VESC already publishes eRPMs. xesc_ros driver get an additional "motor_pole_pairs" parameter which default to "4" so that existent installations without that "motor_pole_pairs" parameter show some reasonable RPM values... even though they might be wrong with the default "motor_pole_pairs=4" parameter. Who cares ;-)?!
• xESC2040 would need an FW update in my point of view. FW probably already has (e)RPMs, but don't get published in status packet. Unfortunately I currently don't have an xESC2040 dev-mower here :-( (but outside mowing my lawn). So, xESC2040 will show RPM=0 at the moment. Because xESC2040 isn't very public, I prefer to wait till someone ask/request this negligible feature (nobody requires in real). If someone would request for it, my current plan is to add a second xESC2040_Status_v2 packet for those with the newer xESC2040 (RPM supporting) FW. Except someone has a better idea to upgrade xesc_ros packet without forcing all xESC2040 user to update their FW (which would be a pain)

Required submodule PRs:

• Feature/rpm xesc_ros#3
• Add RPM description & republish sensor_info if changed xbot_monitoring#5
• Add RPM type/description xbot_msgs#3

For sure, I also plan to add the RPMs into WebApp, but not sure at the moment when ;-)

Also not to forget:

• Feature/fancy sensors OpenMowerApp#7

The next (dry) days I'll test it in real on my ubuntu mower where I'm able to compile, and once the build-image CI work again, I can test the compiled image on the other one, which happily also has some other ESC config.

[rovo89]

registerSensors() seems to do much more than the previous code. Maybe introduce a parameter to call a "lite" version of it?