<vector>: Avoid off-by-default warning C4365 in vector<bool> copy algorithms with /J

[StephanTLavavej]

Reported by a major customer.

Our policy is that we attempt to be /W4 clean but not /Wall clean, as /Wall contains a large number of extremely noisy warnings, many of which aren't suitable for using in production (some are intended for focused investigations, or were added for one unusual scenario, or were just way noisier than their value proved to be).

However, we generally do attempt to keep the codebase clean with respect to the off-by-default warning C4365, as we build our tests with /w14365:

STL/tests/std/tests/prefix.lst

Line 6 in 4634ad4

* PM_CL="/FIforce_include.hpp /w14365 /w14668 /w15267 /D_ENFORCE_FACET_SPECIALIZATIONS=1"

Under the extremely obscure compiler option /J, char is treated as an unsigned type. This triggers C4365 signed/unsigned mismatch warnings when assigning promoted int to char in the vector<bool> optimization for copy() implemented by #3353 (merged 2023-09-21, shipped in MSVC Build Tools 14.39 / VS 2022 17.9).

Avoiding those warnings is easy, so even though /J is rarely used, and we don't officially support being C4365 clean, we may as well silence them and add test coverage.

Enabling the test coverage is significantly more obnoxious but all of the issues were in the test itself and are avoidable with repetitive casts.

[StephanTLavavej]

@davidmrdavid I've pushed a commit to use unsigned char in these functions. Even if it doesn't help with the warning, I agree that it's conceptually cleaner to remain in the unsigned domain, and to avoid char squirrelliness. (I also changed the comments since it was weird to say plain "char", but left the _ch naming.)

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

I had to push an additional commit because /clr:pure is incompatible with life /J.

[davidmrdavid]

re-approving post unsigned char and pure incompatibility fixes. LGTM!