support NEF/ARW/DNG raw formats and zero-padded image IDs

[ManuelOsburg]

Adopted and reworked from the annatroff/LEDSAwindows fork:

• extend the raw format whitelist in image_reading by .NEF, .ARW and .DNG (rawpy reads them already; EXIF works with the existing exiv2 binding) and raise a clear ValueError for unsupported extensions instead of failing with UnboundLocalError
• fix a path bug in ConfigData.get_start_time where directory and file name were concatenated without a separator inside os.path.join
• add image_handling.format_img_name and use it wherever image names are built from the config template: plain {} placeholders now keep zero-padded IDs such as '0001' (DSC_0001.NEF), while numeric format specs like {:04d} still receive an integer

The int() casts previously applied before formatting broke camera series with zero-padded file counters. Unit tests cover the extension routing and both formatting paths.

[ManuelOsburg]

Hi Kristian,

I pushed one more commit to this PR (d674cee), because the change of the image IDs had two side effects:

• Acceptance tests. Since plain {} placeholders keep the zero-padded ID, the template test_img_{}.jpg of the test library resolves to test_img_0001.jpg, while the generated images are test_img_1.jpg. Every Robot suite from S3 on failed. The test library now uses test_img_{:d}.jpg, the template for unpadded file names.
• ConfigData. get_start_time and in_time_diff_to_img_time still called img_name_string.format() directly. Templates with a numeric format spec such as {:04d} failed there with a ValueError. Both now use format_img_name.

Tests: unit tests pass, and Robot suites 02–06 pass. S1 fails on Windows independently of this PR; I'll open a separate issue for it.

One point to decide: existing configs that use {} with unpadded file names (img_1.jpg) need {:d} after this PR. If you prefer to keep them working unchanged, format_img_name could fall back to the unpadded name when the padded file does not exist. Let me know and I'll add that.

Best,
Manuel