AP_Proximity: prevent buffer overflow in LD06 driver

[peterbarker]

We're using a value off the wire before it has been validated. That value is used to limit indexing into a buffer, and that buffer isn't big enough to handle all possible "bad" values that index could take on. Note that "read" here returns int16_t....

I've tried to simply make minimal changes in this driver to avoid the buffer overrun.

[tridge]

@peterbarker if this PR can't be easily tested then we could do a much simpler patch that just checks the array bounds before adding data. That would prefer the buffer overrun while being a minimal change

[rishabsingh3003]

Unfortunately, I dont not have the sensor either so I cannot test. Thanks @peterbarker for getting this fixed!
@lvale I remember you had helped test this driver when we had this merged, would it be possible for you to test it?

[burgeruser]

Hello, I have an LD06 laser radar that I purchased early this year. Unfortunately, its performance is subpar; it has a short range of only 12 meters, and the measurement noise is significant. As a result, the SLAM mapping using Cartographer algorithm does not yield satisfactory results.

Unfortunately, the model has become obsolete since it was quite niche. There are now many cheaper, lighter, and more accurate alternatives available in the market. In my testing with the LD06 on the developer version of Ardupilot4.5.0, directly connecting it to the flight controller for obstacle avoidance proved unreliable. The original 'AP_Proximity_LD06.cpp' file, which handles UART communication, heavily utilizes the STM32 microcontroller's RAM and lacks redundancy. In case of a physical UART cable error, it fails to parse data properly. This file tends to cause issues on STM32F4 platforms but runs smoothly on STM32H7 ones.