Chore: Centralize Strong<> type unwrapping

[reneme]

Closes #4029.

This introduces wrap_strong_type<> and unwrap_strong_type() that opportunistically wrap a given object into a strong type or extract the value from a strong type. It is meant to be used in generic contexts where we may or may not have to deal with a strong type. Examples are the load/store methods and checked_cast_to.

Another new helper is strong_type_wrapped_type<>. Given a potentially strong-typed type, this figures out the underlying type. That is quite useful to build generic functions that take both a bare value or a strong-type of the bare value. Like so:

template <typename T>
   requires std::signed_integral<strong_type_wrapped_type<T>>
void foo(T signed_int_that_may_be_wrapped_by_a_strong_type) {
   const auto bare_signed_int = unwrap_strong_type(signed_int_that_may_be_wrapped_by_a_strong_type);
   /* ... work with bare integer ... */
}

// For future reference: I would have loved to define a higher-order concept
// instead of `std::signed_integral<strong_type_wrapped_type<T>>`.
// In imaginary syntax that might have looked like that:

template <typename T, template <typename> typename SomeUnaryConcept>
concept maybe_strong_type_of =
   (concepts::strong_type<T> && SomeUnaryConcept<typename T::wrapped_type>)
   ||
   (!concepts::strong_type<T> && SomeUnaryConcept<T>);

// The function above could then be defined as:
template <maybe_strong_type_of<std::signed_integral> T>
void foo(T signed_int_that_may_be_wrapped_by_a_strong_type);

Many other generic locations that currently use byte-buffer-ish strong types don't have to rely on this, as those strong types masquerade as byte buffers and can be used directly. This is mostly targeting int-based strong types where we really need access to the underlying object for low-level operations.

We may or may not add this to 3.5.0 as it is a low-level refactoring. I'm quite confident in the CI coverage of this, though.

[reneme]

This is an extra layer of abstraction to make load/store work with integer-enums as well. I feel that this would be useful for the other usage locations as well, so in theory we could also promote that into the implementation in strong_type.h. As a result, the checked_cast_to would then automagically work with enums as well.

[FAlbertDev]

LGTM. I admit I mostly looked into the tests to see if every case was covered 😝
The only thing I can think of otherwise is support for strong types of strong types. In this case, loadstore does not accept these strong-ception types. But I don't think we want to support this anyway.

[reneme]

Yeah, I did wonder about that. But rejected the idea of strong type-ception as useless. Perhaps we should even statically check that in the strong type implementation.

[randombit]

Bumping this to 3.6, with just 2 days until 3.5.0 release I'd rather not change anything except where we must.

[reneme]

This was inspired by #4175 (comment) and it simplifies the code of strong_type_unwrap() significantly. In a sense, that it can now rely on overloading instead of explicitly std::move()ing based on the type of object passed in.

[coveralls]

coverage: 92.045% (+0.3%) from 91.699%
when pulling 0f465bd on Rohde-Schwarz:chore/strongtype_unwrapping
into 45be74e on randombit:master.