Partial elimination of TMP from xutils.hpp and patches for dependencies

[spectre-ns]

Checklist

• The title and commit message(s) are descriptive.
• Small commits made to fix your PR have been squashed to avoid history pollution.
• Tests have been added for new features or bug fixes.
• API of new functions and classes are documented.

Description

With concepts and constexpr the library can be more readable and less reliant on recursion. This PR is the first of hopefully many that will flatten the template structure in xtensor logic without changing public interfaces or functionality. The goal is to make additional optimizations and functionality easier to reason about and implement moving forward.

Additionally, eliminating recursion should help compile times!

[codspeed-hq]

Merging this PR will not alter performance

✅ 255 untouched benchmarks

---

_{Comparing spectre-ns:sfinae-to-constexpr (62d19f4) with master (1b5325b)}

[spectre-ns]

@Alex-PLACET @JohanMabille please let me know if these types of changes are in the direction you'd like to see xtensor move towards!

[JohanMabille]

@spectre-ns thanks for tackling this!

let me know if these types of changes are in the direction you'd like to see xtensor move towards!

Yes and "maybe", depending on the primitives we're talking about:

• I think all the has_xxx metafunctions could actually just be concepts since concepts can be used as compile-time boolean values. It might be worth renaming them for syntax "aesthetic" reason, because has_xxx sounds like a function call and I would expect () after it. So has_strides could become strided_expression for instance (I don't have a good name for has_data_interface); these sounds less like boolean functions only and are closer to the concept naming pattern in the STL.
• Regarding metafunctions returnig types, like get_value_t, I am more hesitant. If we only use get_value_t, then get_value is an implementation detail, and I agree that having a constexpr function makes it more readable. I just find weird to write decltype(some_constexpr_function), but I'm definitely biased by years of pre C++17 metaprogramming here ;)
• We could be more systematic with these get_xxx_t helpers to avoid a lot of typename type::xxx in the code base (for instance storage_type could have its dedicated getter that would make the code easier to read). Probably not all inner types should have such a getter, but those we access the most should.

Please do not take this as assertions about what we should do, this is more a global thinking to gather thoughts and open the discussion. Whatever we decide to do in the end, the goal should be to simplify and reduce the amount of code to maintain.