Raise C++ standard minimmum to C++17 for OIIO 3.0

[lgritz]

Raise our C++ standard to C++17 minimum (from 14).

This also includes bumping all of the compilers we support to have whatever minimum versions are necessary to fully support C++17 (we think this means gcc 9.3, clang 5.0 (or maybe 8.0?), MSVS 2017 / v19.14, icc 19.0).

Note: we should not merge any of these changes until after April 1.

A non-comprehensive list of sub-tasks, not necessarily in order:

### Tasks
- [x] platform.h -- enforce the new minimums, clean up things that only need to be defined for < 17, wide rename of things like OIIO_CONSTEXPR17 -> constexpr, etc.
- [x] INSTALL.md -- document the new minimums
- [x] externalpackages.cmake -- are there other places where interaction with other packages can be simplified with C++17
- [x] Raise LibRaw minimum to 0.20 because that's the earliest that will work with C++17
- [x] filesystem.cpp and externalpackage.cmake -- remove all the boost filesystem stuff, just use C++17 std::filesystem
- [x] Search for `OIIO_CPLUSPLUS_VERSION` and `__cplusplus` through the whole codebase, look for places where we are conditionally selecting code to have separate C++14 or C++17 clauses.
- [x] Search the whole codebase for the compiler version macros (see platform.h) and remove any conditional compilation of things only needed for old versions like gcc6, etc.
- [x] ci.yml -- remove testing cases of the old compilers or C++ standard.

Food for thought / open questions:

• Should we define OIIO::string_view to BE std::string_view? Or are there still advantages to having our own and we should merely ensure that it implicitly can cast from and to the std one?
• Should any places where we take strings that are obviously file paths also have varieties that directly take a std::filesystem::path?
• Are there uses of std::optional, std::variant, or std::any that we should be using in public APIs?

[artificiel]

do you plan on IOProxy supporting std::filesystem::path , and honour/maintain the value_type (without a round-trip in UTF-8 as currently happens with your handling of wstring)?.

we are evaluating replacements to FreeImage as a dependency of openFrameworks, where we are currently ensuring all path values are maintained as proper native fs::paths across components, so the wide/narrow problem is only dealt at boundaries (ex: receiving a drag/drop notification from OS, down to actually passing it to a lib that actually interacts with the filesystem, presumably encased in #ifdef WIN32 statements (or perhaps constexpr check the value_type)).

there are edge cases where some wide chars are not convertible to narrow, which throws in std::filesystem::path::string(), or returns value in the case of WideCharToMultiByte() — which should be checked for a zero return which indicates problems in conversion (or allocation).

OpenImageIO/src/libutil/strutil.cpp

Lines 1002 to 1004 in 7fc6a7b

	WideCharToMultiByte(CP_UTF8, 0, str.data(), str.length(), &result[0],
	(int)result.size(), NULL, NULL);
	return result;

in short a user could have a path on disk that is inconvertible to UTF-8. the MSVC filesystem implementation incorporates a number of conversion methods, some are non-throwing "lenient" and replace inconvertible things by box characters, which is reasonable for display purposes, but it is obviously lossy and will not resolve to the same file path if converted back to wide.

https://github.com/microsoft/STL/blob/1f6e5b16ec02216665624c1e762f3732605cf2b4/stl/inc/filesystem#L62-L83

[lgritz]

I think it would be good to add std::filesystem::path support to IOProxy (and elsewhere, as needed).

There are neither plans nor non-plans, it just hasn't come up before to the best of my knowledge. It's not high on the list for my own time, but I'd happily review and accept a PR that implemented this.

If you're a newcomer to OIIO, it may help to explain the situation if you know that we only recently (with the fairly new OIIO 3.0) raised our C++ minimum standard to C++17, having been pegged at 14 for the previous few years due to VFX industry compatibility issues. So none of the data types introduced in 17 (such as std::filesystem::path) had really been feasible to put in our public APIs before just a few months ago. Thus, we're a little behind in incorporating that, as well as not really having a lot of experience with it.

Another contributing factor is that most of the developers in our immediate ecosystem work at big studios and develop mostly for Linux, where we can just assume UTF8 works and wchar and other such things that are a constant irritation on Windows (and for which std::filesystem::path was invented, I presume) are not really something we've had to contemplate much. Hence, your statement that there are paths that are not convertible to UTF-8 is shocking news to me!

Anyway, not making excuses, just trying to explain how we got here and say that if you can set us on a more modern (and Windows-friendly) path, we would definitely welcome the guidance.

[artificiel]

thanks for the background info. openFrameworks goes back to 2007, with the naive idea that std::string is fine for filesystem cross-platform paths, and it mostly worked. unicode support per se is not integrated in the core, so users relied on using "safe ASCII" names on the file system, or unicode-specific extensions for typography, and got things done, with the implicit assumption that most projects are one-off, and generally under the operation of it's developper. but more and more people are using unicode in filenames which makes it more irritant, and more importantly projects are being distributed as "apps" to "end users", even on Apple App Store. that was not a planned design point for OF, and we're not fighting it but obviously if such "end users" can't make use of their assets normally, it's not a great outcome.

btw OF is C++17 only since last year (in our case it's more of an idea of allowing oldest machines to run older projects, until it's really inconvenient). so I was not really interested in windows unicode (don't even have a windows machine!) but ended up ingesting a fair amount of info, in order to be able to make sound decisions. (one surprising tidbit is that since URLs are UTF-8, a web server on a windows filesystem has a tricky problem to solve (they do it by filtering the wide file names, so the filenames of your received files are actually "sanitized" and not 1:1 what they were on disk).

within a C++ program, std::filesystem::path resolves the problem in a way by encapsulating the format, but it's not perfect either because not truly cross-platform (you need auto and constexpr to switch). but it has other advantages, such as abstracting the root drive, the separator character, etc. I think your ping-pong approach could work with std::u32string as the intermediary format, but that would still need to be confirmed.

our current state of mind is to keep paths as paths as much as possible, and hand them to our dependencies, for instance FreeImage pseudo-code:

void loadImage(const std::filesystem::path& filepath) {
    ofImage image;
    if constexpr (std::is_same_v<decltype(filepath.native(), std::wstring>) {
        image = FreeImage_LoadU(format, filepath.c_str()); // c_str produces wchars; loadU is for wide strings
    } else {
        image = FreeImage_Load(format, filepath.c_str()); // c_str produces chars
    }
}

for displaying, we are probably going into implementing a lenient method that "sanitizes" with square or ? characters where conversion is not possible. but all this is in flight, currently being tried in different ways, so you are now part of the brainstorm! and just to be clear yes we are newcomers to OIIO, currently checking out the landscape of available APIS for read/write libs, and OIIO is one of the few that seem appropriate, but that analysis is not complete yet (independent of filesystem stuff).

[lgritz]

To what degree would it solve your problem if OIIO added overloads for std::filesystem::path to the various main open() calls where it take filenames? Is that mostly what's needed from an app point of view?

[artificiel]

both approaches are fine — as such FreeImage (snippet above) does OK even if it does not support fs::path, because it does support wchar, so if constexpr can be used to detect the flavour to determine which call to use.

but as you write, an overload for fs::path that maintains the wstring "unmolested" until presentation to the OS open calls (and presumably internally doing a condition to select a proper interface) would be the ideal API.