Fix Imf/Iex/IlmThread namespaces in python bindings and website code

[cary-ilm]

Use OPENEXR_NAMESPACE, IEX_NAMESPACE, ILMTHREAD_NAMESPACE instead of Imf, Iex, IlmThread, to support custom settings.

Address #1567.

[lgritz]

This may be fine for now, but I feel like there is a more sensible way to structure the namespaces and namespace override options. I don't need to use these macros throughout the code in my other projects. There should only be two mentions of the "INTERNAL" namespaces -- once in the CMake to allow users a way to override it for a custom namespace, and then a second in a header that aliases the publicly visible namespace to that one. All user code, and all other internal code, ought to be able to safely say Iex::foo and it's fine, even though there is a custom namespace behind it all.

[cary-ilm]

This broke when I added the website example code to the build, and looking at the code more carefully now, it makes inconsistent use of explicit namespaces. What's the prevailing sense of whether example code in documentation should use explicit namespaces? Or assume there's an implicit using? For example, in this code:

void
readRgba1 (const char fileName[], Array2D<Rgba>& pixels, int& width, int& height)
{
    RgbaInputFile file (fileName);
    Box2i         dw = file.dataWindow ();
}

This code on the website is an implicit statement of preferred usage policy. Should Array2D, RgbaInputFile, and Box2i appear as Imf::Array2D, Imf::RgbaInputFile, and Imath::Box2i? I'd say yes.

[cary-ilm]

I've removed the explicit Iex:: namespace from the example website code, and added using namespace IEX_NAMESPACE to all.cpp (which doesn't appear on the website but is used by the build to confirm it compiles), which is at least for the moment consistent with the implicit using namespace IMATH_NAMESPACE and using namespace OPENEXR_IMF_NAMESPACE.

This compiles with both default and custom namespaces, so resolves #1567. Let's flag as a separate issue both cleaning up the namespace declarations and editing the example code to both show best practices as well as work under all build configurations.