Add remove_cvref type trait

[dhollman]

The remove_cvref type trait is added in C++20. It is useful for instance when using SFINAE on a function that take a forwarding reference. Until now we were typically using std::decay instead.

[dalg24]

Why would you use identity here?

Suggested change

	struct remove_cvref : identity<typename std::remove_cv<
	typename std::remove_reference<T>::type>::type> {};
	struct remove_cvref : std::remove_cv_t<std::remove_reference_t<T>>::type> {};

Also please comment this is added in C++20

[crtrott]

does clang 11 have this in C++20 mode already?

[dalg24]

If it supports C++20 it has it.

[nliber]

The suggestion from @dalg24 is cleaner, as we are deriving from another type trait, which already gives us the embedded type member. identity makes more sense when we don't have that, because it is more declarative in that it allows the body of the type trait struct to be empty.

It is also cleaner because of less use of typename. Many of the type traits from vendors aren't using the _t versions because those didn't appear until C++14 and they have to be backwards compatible to C++11.

Separate issue: given that C++20 settled on the name type_identity for this, we should change ours too.

[dalg24]

NOTE to reviewer: I dropped the changes from #3339, rebased onto develop, and applied the suggestion I made since nobody provided a rational for using identity_t.
I am also proposing we just pull it from the standard library when C++20 is used.
I am unsure what is going on with clang-format.

I went ahead and applied the changes I had suggested

[crtrott]

The clang-format thing is interesting it looks like we have just that tiny small difference regarding closing of nested template parameters. The thing is: it seems that if the file wasn't changed in the first place it doesn't care either way, but if it applies any other change it tries to change the >> thing. Really weird.