`<cvt/meow>`: Remove the `cvt` subdirectory

[StephanTLavavej]

The cvt subdirectory contains extension headers providing code conversion machinery. I believe they're rarely used, and have an unknown number of performance and correctness issues. We should deprecate them in favor of simply calling MultiByteToWideChar() and WideCharToMultiByte(), ideally removing them in vNext.

(If we didn't have this subdirectory, we wouldn't accept it as an extension now.)

[AlexGuteniev]

Deprecate every exported public symblo from it.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting, and we're all in favor of deprecating <cvt/meow> (with an escape hatch as usual).

@AlexGuteniev's suggestion of deprecating each publicly visible top-level name (instead of attempting to deprecate each header as a whole via the old typedef trick) is a good one - thanks Alex!

[frederick-vs-ja]

Is it sufficient to deprecate the stdext::cvt namespace (in every header <cvt/xone_byte> and <cvt/xtwo_byte>, perhaps) only?

[StephanTLavavej]

Good idea. I'd prefer to deprecate every occurrence of the namespace, which is what we did for tr1, instead of trying to find occurrences that are always dragged in. Mentioning it on every occurrence is less confusing.

[CaseyCarter]

#3924 deprecated the contents of these headers. I'm leaving this issue open as a place to discuss when and how we should remove them.

[StephanTLavavej]

The next major version, whatever/whenever that ends up being, would be an opportunity to pursue such a removal. It would raise fewer eyebrows than a mid-cycle removal, and we could tell people to use the final release of v17 side-by-side if they've taken a difficult-to-replace dependency on this extension.

The fact that we never documented this on MSDN / Microsoft Learn should help.

[StephanTLavavej]

I talked to @MahmoudGSaleh today, and he agreed that we should remove <cvt/meow> after VS 2022 in the next major version of VS, aka IDE version 18.x, toolset version 14.4x, compiler version 19.4x. (This is totally distinct from the mythical vNext ABI-breaking release.) Having shipped the deprecation in at least one long-term support release (VS 2022 17.8) will have given users advance notice.

Edit: This is outdated. We can go ahead and remove them in VS 2022 17.11.