fix(exr): suppress exr attributes that interfere with our hints

[lgritz]

Our exr writer uses some special hints starting with "openexr:" to control aspects of the writing, and the reader sets these to communicate some things about the file it's reading.

But what happens if... the actual exr file has metadata of tha same name. Oops, those get carried along and mess with things. We had previously accounted for this by suppressing arbitrary metaname named "openexr:lineOrder" if we find it in the input (the actual lineorder comes from a header field, not named metadata, but OIIO uses the name "openexr:lineOrder" to communicate it back as metadata.

Turns out that there are two more that we need to proactively suppress: "openexr:levelmode" and "openexr:roundingmode". There's no good reason for those to ever be in an exr file (like I said, those names are NOT how openexr itself sets those in a file). And yet, we found at least one example in the wile where it was.

[ThiagoIze]

CI appears to be failing.
Also, if this is OIIO specific data, should we start namespacing them so that conflicts are less likely?

[lgritz]

I just replaced this with an entirely different solution that is simpler and that I like better, the fix is now specific to make_texture.

[ThiagoIze]

So either we overwrite the levelmode with our good info or we erase the bad preexisting levelmode. Either way this gets cleaned up. This looks good to me.

[lgritz]

You pointed out a good issue, which is that currently there is a corner case where the user wanted something called "openexr:levelmode" as metadata but not for it to trigger any special behavior on our end. I just want to acknowledge that possibility and kick the can down the road, as this ticket is the wrong place to tackle such a thorny (but also obscure?) problem.

But I'll review our presumptions here:

• Metadata that starts with the prefix "oiio:" is only intended for OIIO signaling -- information that OIIO sets to be informative to readers, or hints to writers, or other internally carried state.
• Metadata starts with the name of a file format itself, like "openexr:" is meant to give hints from or to that format reader/writer, and should definitely be ignored if encountered by any other format writers.
• Some other prefixes are semi-special, for example ones starting with "Exif:" are exif fields that will be honored by any file format that supports Exif in some fashion.

It is also worth noting that I think OpenEXR is the only format we regularly deal with that truly allows "arbitrarily named" metadata. Most formats have a fixed list by their specification and/or the structure fields of their headers. So really, any conflict between "openexr:foo" and intentional user data is an odd case for sure. It still gnaws at me a little, though, so maybe there is a possible future revision about the rules for how we handle hints vs oiio-specific metadata vs "user" metadata to eliminate any rare edge cases.