Consider switching to C++17

[meator]

C++17 (and C++14) has some reeealy nice features (std::string_view, try_emplace() - very useful in the current implementation of Applications.hh, std::optional, std::variant and more). Even C++20 could be considered but I don't have much experience with it.

[meator]

I didn't consider this issue to be significant, but switching to Catch2 v3 (#142) requires C++14. This means that C++11 will have to be given up in some way anyways. One solution would be to still treat the code as C++11 but compile it with C++14. But I don't consider this a good solution. Why throw out C++14's capabilities when we (must) have them?

Another solution would be to upgrade to Catch2 instead of Catch2 v3. Catch2 is no longer supported. Upgrading from deprecated Catch to deprecated Catch doesn't make sense. The v3 version also contains some improvements briefly mentioned in #142.

Since a switch is necessary, why stop at C++14? Nowadays pretty much every compiler supports C++14 and C++17. C++17 would bring improvements described in the first comment which increase performance and decrease complexity of Applications.hh. C++11 is old and is lacking several features. I don't see any major reasons to keep holding on it.

I will switch j4-dmenu-desktop to C++17 and modify code to use its features. If any compatibility issues (for example if a popular j4-dmenu-desktop package uses a compiler which doesn't support C++17 to compile the package which I find unlikely) should arise, I am willing to make some workarounds or revert this switch alltogether.