std::tuple_size / tuple_element specializations for Corrade containers

[mosra]

Revived from #127. For C++17 auto [a, b] = someType;, among others:

• Containers::Pair, for which the std::tuple_whatever specializations could go into the already-existing Containers/PairStl.h, and a corresponding new C++17-only PairStlCpp17Test.cpp
• Containers::Triple, for which the std::tuple_whatever specializations could go into the already-existing Containers/TripleStl.h, and a corresponding new C++17-only TripleStlCpp17Test.cpp
• Containers::StaticArrayView, for which it could go into the already-existing Containers/ArrayViewStl.h, and a corresponding new ArrayViewStlCpp17Test.cpp
• Containers::StaticArray, into a new StaticArrayStl.h header, and a new StaticArrayStlCpp17Test.cpp as well

The assumption is that there will be more and more C++14/17/20-specific features, so the ton of new files is fine.

The std::tuple_element / std::tuple_size is a C++11 feature already so I wouldn't hide them in any #if compiling_as_cpp17. Having them exposed unconditionally would mean std::get<N>() working with Corrade/Magnum types even under C++11, for example.

• Maybe it would make sense to test them directly in C++11 test files somehow, instead of C++17-only tests that won't be run on half the CI jobs. Like, for example, just trying to call std::get<N>() on them, and if that works, the C++17 structured bindings should work too.

And for Magnum a similar treatment would be done for Math::Vector and possibly other math types, in a similar way.

[mosra]

Done in 5f4fc52, together with structured bindings for StridedDimensions.