Clean up our type_traits headers (again)

While putting together some of the trickery required for the revised reference elements, I got to take a look at our headers with type traits again and noticed a few things:

• It's unfortunate that void_t is in dune/common/typetraits.hh and not in dune/common/std/type_traits.hh. It's also not in Dune::Std. Can we still move it? (This isn't really worth it, see !464 (closed))
• We have again duplicated a bunch of functionality, with Dune::AlwaysTrue<T> vs. Dune::Std::to_true_type<T> and the corresponding false versions. Should we get rid of one of them?
• (!393 (merged)) For 2.5, we added the type trait Dune::Std::is_callable along the lines of N4446, but C++17 did instead get std::is_invocable and std::is_invocable_r (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0604r0.html for the (slightly arcane, but understandable from the EWG point of view) reasoning). This is not just a rename, the committee also changed the syntax by replacing the encoding of the arguments, going from the function-call-like is_callable<F(Args...),R> to a more traditional is_invocable<F,Args...>. The website listed above gives a good reason for that change. So the question is: What do we do with our implementation? Do we deprecate it and replace it with a fallback implementation of std::is_invocable? If we do that, do we also add std::invoke_result?
• I don't get IsInteroperable<T1,T2> and related EnableIfInterOperable<T1,T2,U>. Apart from the naming inconsistency, it checks for a really weird thing: is_convertible_v<T1,T2> or is_convertible_v<T2,T1>. With a quick grep, I could only find it in the iterator facades. And there, it will lead to a compiler error if only one of the two conversions is valid. I'm in favor of deprecating it.
• is_indexable can be simplified quite a bit with our improved compiler requirements. I'll take care of that.
• (!466 (merged)) The combination of CamelCase and stl_like syntax is probably here to stay, even though it might be good to use CamelCase for our own utilities and stl_like for standard library backports.