Add OPENEXR_CORE_USE_NAMESPACE to build OpenEXRCore with C++

[cary-ilm]

When OPENEXR_CORE_USE_NAMESPACE=ON, the .c and .h files in OpenEXRCore are built with C++ rather than C, with all symbols in the OPENEXR_IMF_INTERNAL_NAMESPACE namespace just like the OpenEXR library.

This makes is possible to trade the benefits of the C implementation for the benefits of C++ and the namespacing of all symbols.

All code in the OpenEXRCore .c and .h files is now bracketed inside OPENEXR_CORE_NAMESPACE_ENTER and OPENEXR_CORE_NAMESPACE_EXIT, which add namespace directives (e.g. namepace Imf_3_4 {). These degenerate to empty when compiling with C, which is still the default.

There are also macros OPENEXR_CORE_EXTERN_C_ENTER/OPENEXR_CORE_EXTERN_C_EXIT for the OpenEXRCore code that needs extern "C" {, which reverts the the C++ OpenEXR namespace in C++.

This also adds missing C++ casts to OpenEXRCore, required by C++ even though the are not necessary in C.

Also, the _priv_exr_part_t struct now has a custom constructor and assignment operator because its chunk_table field is a atomic_uintptr_t, which has those methods deleted.

This also includes some necessary changes to the vendored libdeflate code to compile in C++.

When building OpenEXR with the default configuration, this produces the same object code as before. The namespaced symbols are only generated when configured to do so. As as test, I ran nm on the shared library and got the same symbols as before.

Website preview: https://openexr--2205.org.readthedocs.build/en/2205/

[cary-ilm]

By the way, I'm not crazy about the name of this build option, OPENEXR_CORE_USE_NAMESPACE=ON, I'd welcome a suggestion for something better.

[kdt3rd]

I am not a huge fan of this change. I have proposed an alternate method to address the needs of people who want to embed a custom version of exr for some reason to hide the C symbols entirely in #2216