Improve detector distance to XY converter parser

It would be useful for the detector distance parser in `dodal` to be able to load GDA detector distance files without modification.

On VMXm for example, a detector distance file in GDA like:

VMXm det distance file

```
#Table giving position of beam X and Y as a function of detector distance
#Take values from autoprocessing results in SynchWeb
#Or take values from xds (in pixels) and multiply by pixel size 0.075
# 1. DIALS - detector.slow_fast_beam_centre=1277,1303
# Ybeam = slow * 0.075
# Xbeam = fast * 0.075
#Import data to dials.
#Run dials.show imported.expt for currently slow,fast values.
#Open imported.expt in dials.image_viewer and use ring tool to find differences to new centre and subtract from current values.
#Multiply slow fast pixel values by 0.075 to get mm values.
# values updated 03/12/2021
#E2 9M
#dety=732mm
Units mm mm mm
#287 123.15 187.70
#613 123.15 187.70

#dety=718mm
Units mm mm mm
#282 123.169 168.479
#613 123.169 168.479

#dety=704mm
Units mm mm mm
#282 123.169 154.386
#613 123.169 154.386

#MX Settings
#dety=676
Units mm mm mm
300 123.35 131.77
593 123.35 131.77

#613 123.2 126.2
#
##

# To load lookup table go to jython terminal
# type reloadLookupTables()
```

failed to parse (due to using _multiple_ spaces as a separator, in this case).

This issue is to adjust `dodal`'s parser to be able to cope with this kind of file, and to write corresponding tests to prove it.
- Suggest gathering a representative sample of these files from MX beamlines and using those as unit-test cases.
- Check the parsing logic used by java to see if there are any other cases we're cot covering properly
- Making `Units` a "comment" seems wrong, is this going to catch us out if some beamlines start defining different units?
* I feel we should at least be _checking_ that the units are what we expect.

Once this issue is done, make `hyperion_fast_grid_scan` in GDA point at `DetDistToBeamXYConverter_E9M.txt` on VMXm and delete the `_hyperion` version.