Switch from C++14 to C++17

[s3rvac]

We have discussed this and it seems that the time has come to switch from C++14 to C++17.

Reasons:

• It is already 2019. All major compiler vendors and standard-library implementers support C++17 (at least the features that we would like to use, see this table and the one below).
• We could replace e.g. Maybe with std::optional, FilesystemPath with std::filesystem, mpark_variant with std::variant.
• The new version of yaramod (currently under development) will require C++17. As we use yaramod in RetDec, we will also need to switch to C++17.

The switch to C++17 would not mean that we will update all of our code to C++17 at once. The transition will be gradual, starting with what we need the most.

[ceeac]

One thing to note is that std::get for std::variant is not available for macOS 10.13 so you might have to bump the minimum required macOS version to 10.14 for full std::variant support.

[s3rvac]

Thank you for the note. Yes, we will have to figure out the minimal versions of operating systems, development environments, compilers, etc. and bump them.

[PeterMatula]

Our CMake now requires C++17. I also replaced some obvious stuff like mpark_variant or utils::Maybe with std::variant and std::optional. Also, I fixed some warnings, but there are many more on Windows - but there is another issue for that.

I also tried to use std::filesystem instead of our own implementation, but it turned out this is not the best idea at the moment:

• On Linux, it requires GCC >= 8.
• On Windows many regression tests failed. There are probably some minor differences, or we use it incorrectly.
• Both <filesystem> and <external/filesystem> are missing in macOS < 10.15. Right now we don't have this version in TeamCity, nor Travis CI.

So I decided to throw away the new code and wait a little longer with this particular improvement until <filesystem> is widely available.

Also, C++17 allows many more improvements of our code, but these features will be used gradually in new/refactored code.