fix(exr): don't suppress "oiio:ColorSpace" attribute on output

[lgritz]

It looks like for some time setting the "oiio:ColorSpace" attribute when outputting an openexr file just got dropped on the floor. I don't think this was the original intended thing to do.

I'm adding it mainly as a short-term band-aid. I think in the long term, it is better to have a cross-project/industry consensus on how to express color space in an exr file, and to coordinate OpenEXR + OpenImageIO + OpenColorIO + DCCs about any necessary conventions. I will open a separate discussion about that.

But in the mean time, maybe this fix helps avoid the problem of having total amnesia about the color space information when we do a "OIIO write exr -> file -> OIIO read exr" round trip.

[lgritz]

I should point out a potentially critical issue here: This introduces the possibility that an OIIO-based app can write the "oiio:ColorSpace" attribute, then a non-OIIO-based app can read it, apply a color space transformation, then write the result and simply pass along all the metadata, including this one, unaware that it now inaccurately declares the color space of the image. Which is not only misleading, but potentially could influence the behavior of other OIIO-based apps that subsequently read the new image. Is this better or worse than the files simply not having any information about their color space?

Many studios and apps, by convention, assume that if the filename, like foo.acescg.1001.exr, contains a color space name, that accurate reflects its contents. What happens if the oiio:ColorSpace attribute contradicts the naming of the file? Which hint should "win"?

I think this is why this simple change has languished in my private tree for 9 months without my quite turning it into a PR. I'm very nervous about meaning well here but creating more new problems for people than I'm solving.