Description
Describe the bug
When a DICOM file is opened that has multiple instances of group 0x0002 (= File Meta Information),
the file meta information is taken from the last instance instead of the first.
I'm aware that this file is technically invalid, but we see instances of this in the wild and other tools like dcmdump can properly handle them.
We noticed this because, when trying to render such a DICOM file, the wrong transfer syntax (from the 2nd segment) is used by fo-dicom.
To Reproduce
I will add a unit test that demonstrates the problem, once I figure out how to anonymize the sample file properly.
Expected behavior
The second (and any other) instances of that group should be considered tags belonging to the data, not the meta information.
Environment
Fellow Oak DICOM version: Latest 5.x
OS: Any
Platform: Any