Enable using string views with wil::str_concat

[jonwis]

This fixes #505

String views are not (necessarily) null terminated. Previously, wil::str_concat required only "things that can be wchar_t const* converted." This change expands that to support string views. Note that there is no wistd::pair<> - one is declared in wistd_type_traits.h but no body is provided.

Note: This includes the same CMakePresets.json update as #589 - whichever loses the race will have it removed.

[dunhor]

It's been too long since I've last thought about this issue, but I wonder - if we're introducing a new function, is there's something we can do to fix this for view_from_string. Reading my past comments in #8, it looks like there's a dependency in existing code on implicit conversions, namely T -> PCWSTR and T -> std::wstring, which makes things tricky... I'll have to noodle on this a bit more, but I'm curious if we can switch to a class template¹ and have the base implementation assume that T is convertible to PCWSTR. This leaves out types that are implicitly convertible to std::wstring, but hopefully there are few enough instances that we can just fix them with static_cast (or more ideally, function calls). My comments in #8 seem to suggest that the main reliance on this conversion was with std::filesystem::path, in which case explicitly calling .native() is probably more ideal anyway since it returns by reference. That said, this is an experiment we'd probably have to carry out in the OS repo to gain better confidence.

[1] Function templates don't allow partial specialization and are therefore not suitable here.

[dunhor]

Side note: we can also maybe provide a specialization for std::filesystem::path in stl.h. The issue there is that due to annoying reasons there's no knowing which <filesystem> we'll be picking up. My hope here is that maybe feature test macros could be used, but I haven't dug into it.

Another possibility is to have detection logic in the base class template for something that is "string view like." E.g. something that has .data() and .size() members, though we need to be careful there - std::array has both .data() and .size() members, so we'd want other checks, for example checking for .length() (perhaps instead of .size()), though I'm not sure if that matches other types we don't want to match against.

[dunhor]

Although it seems my memory is wrong... std::filesystem::path doesn't have .data()/.size() like I thought... It does have .c_str() - maybe we could detect that, although that's wasteful since we know the length... Otherwise, it does have .native() but that's too generic of a name to make assumptions about...

[dunhor]

This is fine. I still want to take a crack at fixing the two-phase-name-lookup issues that arise when using function overloads, but I think it's okay to hold off on that for now. I'm going to need to do those tests in the OS repo anyway