Fix test normalization for integer tokens in space-delimited fields and numeric-string Software

[tonimelisma]

Two small test infrastructure gaps discovered while adding HEIF support:

1. isSpaceDelimitedFloatRe regex too strict

The fuzzy float comparator for space-delimited fields (used for LensInfo,
PrimaryChromaticities, etc.) had regex ^(\d+\.\d+) (\d+\.\d+) which required
both the first and second token to contain a decimal point. LensInfo on some cameras
includes integer tokens (e.g. iPhone 15 Pro: "2.22 9 1.78 2.8" where 9 is the
max focal length in mm). The second token 9 has no decimal point, so the fuzzy
comparison was not applied and the test fell through to exact string comparison,
failing on float64 precision differences.

Fix: change to ^(\d+\.\d+)( \d+\.?\d*)+$ — first token still requires a decimal
(to avoid accidentally matching non-numeric strings), subsequent tokens may be integers.

2. ExifTool emits iOS software version as JSON number

ExifTool with -n outputs "Software": 26.3 (a JSON number) rather than
"Software": "26.3" (a string) when the software field contains a value that looks
like a number. After json.Unmarshal this becomes float64(26.3) in the golden
file, while imagemeta correctly returns string("26.3") (the EXIF Software tag
is defined as ASCII). The comparison failed on type mismatch.

Fix: add "Software" to the normalizeThem switch to convert float64 back to
its decimal string representation when ExifTool has emitted it as a number.

[bep]

This needs to fix a failing test case. As per my previous comment, if this is more practical to do as part of #58 that's fine. But in any case, we need to be able to remove this particular patch and have a test fail.

[bep]

I'll handle this in #58