Bump required C++ standard to c++17

[QuLogic]

PR summary

According to SciPy's Toolchain Roadmap [1], C++17 core features became available in 2022. This was concluded based on minimum compiler versions in manylinux2014 images, AIX systems, FreeBSD systems, and Windows. Note, some standard library features are not universally supported.

This commit does not move much code to C++17, just a couple of minor improvements that I could easily change.

[1] https://docs.scipy.org/doc/scipy/dev/toolchain.html#c-language-standards

PR checklist

• [n/a] "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• [n/a] Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines

[WeatherGod]

I see config changes and docstring changes, but no code changes. Are there more commits coming or is this it?

[WeatherGod]

extraneous paren

[QuLogic]

No, this is C++11 raw string literal syntax; it's R"<something>(...)<something>" where <something> is an optional string to prevent ambiguity if your string might contain )". I chose additional double quotes to make it look similar to a Python multiline string, but if that is confusing a different string could be chosen.

[WeatherGod]

Oh! Yes, it is! Actually, let's keep it this way. I just haven't encountered it enough to recognize it for what it was.

[oscargus]

This should be updated as well:

https://matplotlib.org/stable/devel/dependencies.html#c-compiler

[QuLogic]

I see config changes and docstring changes, but no code changes. Are there more commits coming or is this it?

From my point of view, that is all. This is primarily intended to allow new features by keeping up with the rest of the ecosystem, but I am far from an expert in modern C++ and what we could actually use. I expect @anntzer or @ianthomas23 will have a better idea of that.

At the very least, I do know that mplcairo uses C++17 and so if we're finally at the point where we can allow it, then we can start thinking about integrating/depending on that in the future. Also, C++14 will be useful for some of the overload handling code in #27011 (which is why it doesn't currently build.)

[WeatherGod]

There is a test failure. A blitting test using tk. No clue if it is related to a change in compilers.

[tacaswell]

Restarted the failed job. tk + blitting + osx is a known flaky test.

[ianthomas23]

I expect @anntzer or @ianthomas23 will have a better idea of that.

One tangible benefit is use of std::optional (or possibly std::variant) when passing np.ndarray | None via pybind11 to C++ so that we can explicitly check the None-ness rather than relying on automatic conversion to a np.ndarray and inferring None based on the ndims or shape.