DFReader: Read unit data from log and add dump_verbose function to DFMessage

[shancock884]

The main aim of this PR is to make the DF log reader 'unit aware', by reading the UNIT and MULT messages from the log, and then storing the resulting units as part of the format definition.
In order to test it, the update also adds a dump_verbose method which is used by mavlogdump (and later MAVExplorer dump command, with separate PR) when the --verbose argument is used.
(Previously verbose outputs were only available with Mavlink/TLog files)

Note that the multipliers specified in the MULT/FMTU messages do not alter data values (so nothing should be unexpectedly different to any users or other tools), but rather amend the unit with a suitable prefix. e.g.: Ah * 1e-3 => mAh.
This is in line with the logic used to populate the wiki.

Implementation notes:

Cache units and multipliers in unit_lookup and mult_lookup lookup tables when first scanning the DFBinary or DFText file.
When applying the FMTU message to the format, compute and store the derived unit for each field as DFFormat class attribute.
Added get_unit method on DFFormat to return unit if defined or empty string if not.

Create dump_verbose function on DFMessage class, which outputs both value and unit for each field.
Also show the deg or deg/s value for rad or rad/s fields

Separate code to detect quiet nan into a utility function, so it can be used by both __str__ and dump_verbose functions.

Improve display precision of values which have a multiplier attached to their format....
For things like latitude/longitude, I noticed that Python was printing unexpectedly long numbers, e.g.:
>>> 401952592*1e-7 # gives: 40.195259199999995
And I found that by converting the multiplier to a divisor, you get a much cleaner value displayed:
>>> 401952592/1e7 # gives 40.1952592

mavlogdump.py updated to call the dump_verbose method when --verbose specified
I have used hasattr to check the new method exists, in case of misaligned files - probably not so important for mavlogdump.py, as this and DFReader.py are both part of same Python package, but I thought it was safer when doing the same in MavExplorer, as its packaged in MAVProxy.

Testing

Tested with both DF binary and DF text files, using mavlogdump. An example of the output follows:

$ mavlogdump.py --verbose ArduPlane-Soaring-00000045.BIN --types POS
2024-01-07 11:46:53.019: POS
    TimeUS: 8025122 µs
    Lat: -35.362938 deglatitude
    Lng: 149.165085 deglongitude
    Alt: -0.14999999105930328 m
    RelHomeAlt: -0.15874642133712769 m
    RelOriginAlt: qnan m

$ mavlogdump.py --verbose ArduPlane-Soaring-00000045.log --types BAT
2024-01-07 11:46:46.799: BAT
    TimeUS: 1805111 µs
    Inst: 0 instance
    Volt: 12.6 V
    VoltR: 0.0 V
    Curr: 0.0 A
    CurrTot: 0.0 mAh
    EnrgTot: 0.0 W.h
    Temp: 0.0 degC
    Res: 0.0 Ohm
    RemPct: 100 %
    H: 1

(And thanks @peterbarker for pointing my at your units branch - it was useful to compare and update what I had started).

[peterbarker]

This is no slower than master.

[peterbarker]

I wonder if we should go via dump_message_verbose here, even 'though we do have an object (that we control) to call methods on.

[peterbarker]

Merged, thanks!