[lib] Replace uses of add_meow_t with plain cv-qualifiers

[frederick-vs-ja]

...except for [tab:meta.trans.cv]. Because the wording change for add_cv seems a bit non-trivial.

Fixes #7845.

[Eisenwave]

There may be additional uses of std::add_lvalue_reference or std::add_pointer which aren't needed, but that's probably best done in a different PR. It's also less obvious whether the uses of those traits are pointless because they have some special behavior.

[jensmaurer]

There may be additional uses of std::add_lvalue_reference or std::add_pointer...

Those should not be in this pull request.

[frederick-vs-ja]

There may be additional uses of std::add_lvalue_reference or std::add_pointer which aren't needed, but that's probably best done in a different PR. It's also less obvious whether the uses of those traits are pointless because they have some special behavior.

I believe that LWG4144 made uses of add_lvalue_reference_t pointless for unique_ptr. (Edit: This seems to be wrong, per this demo.) For the example in [exec.util.cmplsig.trans]/2, I think the use of add_lvalue_reference_t is also pointless, although add_lvalue_reference_t seems able to trigger more "accept-invalid" compiler bugs.

Other uses of add_lvalue_reference_t are meaningful since they handle std::common_with<void, void>.

For add_pointer_t, most uses are meaningful because they remove references. Its uses in std::get_if overloads are possibly meaningful but squirrelly when invalid variant specializations are involved (Godbolt link). Perhaps an LWG issue is necessary for this.

[jwakely]

This changes the mangled name for std::as_const specializations, but I don't think we need to care about that.

[jwakely]

It is a normative change though, so not editorial.

[jensmaurer]

Understood; @frederick-vs-ja , please remove this change from the present editorial pull request and (at your option) create an LWG issue.

[frederick-vs-ja]

Reverted.