px4fmu v2 sensor init (again) and cleanup

[dagar]

This is similar to the fix @svpcom implemented in #8703, except instead of forcing to FMU-v2 in a particular error case this PR defaults to treating the board like a traditional FMU-v2 in all cases where a cube or pixhawk mini aren't detected.

I also dropped the BOARD_HAS_SIMPLE_HW_VERSIONING defines because we don't have a build with that disabled.

Checking sensors status for each board. Pass means all expected onboard sensors found.

Board	after flash	reboot cmd	reset button	cold boot	notes
3DR pixhawk (fmu-v2)	✓	✓	✓	✓	2 x accel, 2 x gyro, 1 x mag, 1 x baro
mRo pixhawk (fmu-v2)	✓	✓	✓	✓	same
bad hobbyking pixhawk (R635 issue) (fmu-v2)	✓	✓	✓	✓	same
new holybro pixhawk (fmu-v3)	✓	✓	✓	✓	same
pixhack v3 (fmu-v2)	✓	✓	✓	✓	2 x accel, 2 x gyro, 1 x baro, internal mag missing
3DR pixhawk 2 (fmu-v2)	✓	✓	n/a	✓	3 x accel, 3 x gyro, 2 x mag, 2 x baro, reset button not accessible
proficnc pixhawk 2.1 (fmu-v3)	✓	✓	n/a	✓	3 x accel, 3 x gyro, 3 x mag, 2 x baro, reset button not accessible
3DR pixhawk mini (fmu-v2)	✓	✓	✓	✓	Only single IMU present, no mag, 1 x baro

[dagar]

@svpcom please test and review.

[dagar]

I changed the default (fallback) behaviour to match what the stock px4fmu-v2 did historically.

I believe the pixhack v3 issue is unrelated, and we simply need to determine what's actually on that board and fit it into the fmu-v2 binary (old bootloader again). I haven't been able to find a good schematic online yet.

[dagar]

Any other scenarios worth testing?

[LorenzMeier]

@dagar None that I could think of.

[svpcom]

@dagar It works for me. Have you any plans to backport it to 1.7.x ?

[dagar]

I'll bring that up on the dev call. Either doing a v1.7.4 point release with a handful of cherry-picked fixes, or releasing master as v1.8.0 soon.