Add support for OpenEXR image format

[brianpopow]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

This PR adds support for decoding and encoding of images in the OpenEXR format. OpenEXR is a HDR image format, therefore I have added two new pixel formats Rgb96 and Rgba128 which store each color channel as UInt32.

The specification can be found here: https://openexr.com/en/latest/index.html#openexr

A reference implementation can be found here: https://github.com/AcademySoftwareFoundation/openexr.git

[JimBobSquarePants]

I know these types are internal but I'm finding it very useful currently to document the crap out of everything (AI really helps here.)

[brianpopow]

I have added more docs with 1e69aa4

[brianpopow]

@brianpopow I'll be able to focus on a proper review this week.

@JimBobSquarePants: dont worry keep your time, it is not urgent.

Just as a heads up: I noticed issues with the pixel conversion methods introduced with the new pixel types. I am trying to add tests for them in the next days. Those conversion methods will change, so maybe exclude them from a review until then, because they will change anyway.

[JimBobSquarePants]

This output looks bugged to me. Has the Magick comparison been hiding an issue?

[brianpopow]

The image looks like this:

The image is from the bmp suite where alot of the edge case image in the tests come from.

From the description of the image:

An RLE-compressed image that uses “delta” codes, and early EOL & EOBMP markers, to skip over some pixels. It’s okay if the viewer’s image doesn’t exactly match any of the reference images.

It looks like the third image in the "correct display" list: the undefined pixels are black.