Arcmantis/warning deprecate WidenFilename

[Arcmantis18]

Marked WidenFilename as deprecated. Suppressed deprecation warnings in unit-tests. Addresses issue #2349

[kmilos]

Btw, IMHO a better approach is to just avoid the warning on Windows altogether. Treat the cause, not the symptoms. So, here:

openexr/src/lib/OpenEXR/ImfMisc.cpp

Line 2002 in 662ec14

std::wstring_convert<std::codecvt_utf8<wchar_t>, wchar_t> converter;

do something like

#ifdef _WIN32
    // add native code based on MultiByteToWideChar() 
#else
    std::wstring_convert<std::codecvt_utf8<wchar_t>, wchar_t> converter;
    return converter.from_bytes (filename);
#endif

And the codecvt usage on Windows is gone, so no warnings there. The codecvt path is kept just for the 3.4 API. When WidenFilename() is eventually removed from the API, just move the native code snippet to an internal utility function that is entirely guarded by #ifdef _WIN32, and the other codecvt path is finally fully gone.

[Arcmantis18]

This sounds good to me. I would like @cary-ilm 's opinion, but I can look into creating another PR if this is deemed necessary.

[kmilos]

I guess you'd still want these pragmas to supress the warnings due to the interim API deprecation and not only codecvt, so that extra change can indeed come separately.

However, I'd suggest also adding TODO comments here to remember to remove these pragmas when the function is actually removed from the API...

[cary-ilm]

Thanks for working on this!

In the tests, I'd prefer to tightly bracket the call to WidenFilename with the necessary pragmas, rather than apply it to the entire file. As is, should some other function get deprecated, we wouldn't see the warning since all deprecation warnings are silenced for everything.

And it looks like WidenFilename is only called inside a #ifdef _WIN32, so you don't even need the clang/gcc pragmas.

And the TODO comments are a good note to clean the code up when WidenFilename goes away.

[Arcmantis18]

Thanks for the feedback. I didn't want to crowd the file with pragmas, but I can definitely wrap each WidenFilename call, as this might cause other problems. Concerning _WIN32, kmilos pointed out earlier that simply relying on _WIN32 may break on MinGW, GCC or Clang compilers with the pragmas, that's why I needed to support each type separately.