Based on microsoft#4627 fixup that extracts `_In_range`
This also makes some place dirctly using `_In_range`,
but mostly `_Max_limit` is used

Co-authored-by: A. Jiang <[email protected]>

This reverts commit dd292a8.

…no_limits

and actually improving throughput

…no_limits

* This was unnecessarily asserting *strictly* less than `ULONG_MAX`, not that it mattered.
* We can/should use Standard `in_range` because `<semaphore>` is C++20.
* We control `_Ten_days`, so this should be an `_STL_INTERNAL_STATIC_ASSERT`.
* As a scalar, `_Ten_days` doesn't need to be `static constexpr`, it can/should be plain `constexpr`.

We know `is_integral_v<_Elem>` and `is_signed_v<_Elem>` so this is definitely ok.

This is `_Integer_like _Int`, which is ok because we handle `_Signed128` and `_Unsigned128`.

The first case is simple: `_Int` is known to be unsigned, and we want the maximum.

The second case requires a bit of thought. `_Int` is known to be signed, and `_UInt` is its unsigned counterpart. This code wants the maximum `_Int`, stored in `_UInt` type. The new function makes this clearer than the old math.

The following headers are no longer including `<limits>`:

* C++14 `<xmemory>`
* C++20 `<format>`
* C++23 `<mdspan>`

The installed base of C++20/23 code is far smaller, and far more modern. We don't need escape hatches for them.

However, we should have an escape hatch for the `<xmemory>` change, as I expect that this will otherwise be too disruptive.

Co-authored-by: Alex Guteniev <[email protected]>

…de `<cwchar>` in `<limits>`".

Co-authored-by: A. Jiang <[email protected]>