DICOM: add null imageIO handler to allow parsing of DICOM data even with unsupported transfer syntax

[jdtournier]

This at least allow mrinfo to run. Any operation that attempts to access the voxel data will of course fail.

[jdtournier]

For info: the motivation for this is to at least allow mrinfo to report the contents of a DICOM dataset even if the voxel data are stored in a compressed format that we can't currently handle (e.g. JPEG)

[Lestropie]

I had wanted to test this on some local data with unsupported transfer syntax, but am now having trouble finding any. I do plan on generating some at some point using the local scanner in order to evaluate scope of current support and prospect of better support (eg. #2675) and to augment the testing suite, but have not yet found the time to do it.

I nevertheless checked the code at the time and was happy with it (over and above aef44bb). Only other thing to consider would be version-matching the documentation hyperlink, but that's not requisite for the PR.

[Lestropie]

Actually, in retrospect, the documentation shows mrinfo failing due to unsupported transfer syntax, whereas with this change, mrinfo will succeed but others will fail. So that example should ideally be updated.

[Lestropie]

Found some unsupported data. Works as intended at my end, though the user feedback is perhaps sub-optimal:

• mrinfo issues the full warning, but then reports header information anyway, without any specific message about being able to read the header but not the intensity data;
• Any other command first issues the same warning, then reports as error "No suitable handler to access data". This is because the same Exception class is thrown regardless of whether a handler is incapable of accessing an image vs. there was some issue in the appropriate handler reading the image. Transitioning to STL standard exceptions (which we've discussed, but is not a C++17 thing, and doesn't yet have its own Issue) would potentially facilitate disambiguation here. Not a dealbreaker though.

[Lestropie]

57c0579 resolves 2 of the 3 concerns I raised about documentation & terminal messages. I think that improves self-consistency and maybe decodes what's going on a little bit for any users who manage to encounter it.

[Lestropie]

This requires review by someone other than myself or @jdtournier as we can't approve our own changes to master.