Add support for BMP388 barometer

[modaltb]

Describe problem solved by this pull request
Originally this was submitted here: #13128
It was recommended to issue this PR directly on master instead of the v5x branch as this driver is needed by an upcoming PR for 'modalai_fmu-v5m' BSP.

Describe your solution
Flight tested using the I2C interface. Our HW doesn't have the SPI interface so this has been left in but is 'untested'. The noise and update rates were compared to a Pixhawk 4 Mini and it's comparable if not less noisy.

Describe possible alternatives
NA

Test data / coverage
We have been flight testing this with our hardware for the last months. Recently made some measurement improvements by oversampling and altitude hold is stable.

Additional context
#13128

If this merges to master, I'd suggest getting rid of these stale branches:
https://github.com/PX4/Firmware/commits/pr-bmp388
https://github.com/PX4/Firmware/commits/pr-bmp388_initial

[LorenzMeier]

Please rename the fmuv5m board target - all FMUvAb names are reserved for industry standard targets that are binary-compatible across manufacturers. A recent example for a non-standard board that we added was “durandal”. I would recommend a similar naming pattern.

The only targeted v5 series boards are v5 and v5X and there is no plan to add a third series, which would lead to additional fragmentation of our test matrix.

[dagar]

If possible I'd prefer we carry this without the Bosch header (bmp3_defs.h). It looks like a lot of the registers and structures aren't used. Thoughts?

This PR doesn't introduce the board support, but the name change request has been noted.

[modaltb]

@dagar Agreed, let me yank out bmp3_defs.h as that's adding a lot of unused code.

Also, I'll refactor the 'fmu_v5m' to something else before getting to the board support PR.

[modaltb]

@dagar per the slack chat, I changed the fmu-v5 stackcheck to only use the ms5611. Let me know if I mis-interpreted!