ImageReader, TextureLoader : Remove special case for png colorspaces

[ivanimanishi]

OIIO 3 doesn't have "linear" built-in anymore, and it now needs to come from the config.

This is causing errors when trying to open png files, as often there isn't a colorspace specifically called "linear".

The original reasons for hard-coding that colorspace don't seem to apply anymore, neither ImageEngine nor gaffer are loading UI icons that way, so it seems reasonable to remove it, and treat png files just like any other image.

Generally describe what this PR will do, and why it is needed.

Checklist

• I have read the contribution guidelines.
• I have updated the documentation, if applicable.
• I have tested my change(s) in the test suite, and added new test cases where necessary.
• My code follows the Cortex project's prevailing coding style and conventions.

[ivanimanishi]

@johnhaddon , see if you have any issues with this fix. We are trying to switch to OIIO 3 / Gaffer 1.7, but are getting some unittests failing because they can't read pngs anymore.

As stated in the PR description and commit message, I can't see any obvious other issue with the pngs in UIs, which was the reason why Andrew added the special case there in the first place.

@danieldresser-ie thought this fix is a reasonable one, but there is a potential discussion about the way all the other image formats were being read, but I'd prefer to limit this PR to the immediate fix, so we can move forward here, particularly since I don't have clear alternative. But if you think there is a better solution, just let me know.

At IE, we are trying to avoid the use of IECoreImage on new code, but it will still take some time to remove all of the existing ones.

[johnhaddon]

Looking through the Gaffer source, the only thing I can find that would be affected by this is the RenderMan CookierVisualiser, which passes a map filename as a texture parameter to IECoreGL. It seems unlikely that PNG files would be used with that since .tex files are a requirement of the cookie filter.

But this will also affect anything that does texture lookups from a file in a GLSL shader in Gaffer's viewport, so we can't be confident that it won't affect some user-defined setup we're not in control of. We ship an OpenGL Texture shader with Gaffer, and it's not implausible that someone will have thrown a PNG into it. That makes me uncomfortable.

The code we're removing was always pretty hacky. But I think it's a bit of a stretch to say that it's a bug fix when the only visible effects in Gaffer will be unwanted. Looking at the OCIO source I see things like ColorConfig::Impl::identify_builtin_equivalents() that make it sound like it's trying to find spaces like the ones we want. Perhaps they are available under some other name now?