`<type_traits>`: Possible improvements of implementation strategy of `is_scoped_enum`

[frederick-vs-ja]

1. Clang has implemented the __is_scoped_enum intrinsic since Clang 16 (llvm/llvm-project@a089def, LLVM-D135177). But MSVC and EDG don't seem to have it implemented. Should we use __is_scoped_enum for Clang, which possibly improve throughput?
2. As noticed in <type_traits>: Implement is_scoped_enum #1950, MSVC thinks that an unscoped enumeration type without fixed underlying type is complete in its enumerator-list (and generally treats int as its underlying type). This is non-conforming, while a conformance fix is likely to break the current implementation strategy. I think I've found the strategy (see below) working with both conforming and non-conforming treatments. Should we use it or something similar?

void _Test_convertibility_for_is_scoped_enum(...); // not defined
void _Test_convertibility_for_is_scoped_enum(int) = delete;

template <class _Ty>
concept _Is_scoped_enum_impl = __is_enum(_Ty) && requires { _STD _Test_convertibility_for_is_scoped_enum(_Ty{}); };

_EXPORT_STD template <class _Ty>
struct is_scoped_enum : bool_constant<_Is_scoped_enum_impl<_Ty>> {};

_EXPORT_STD template <class _Ty>
constexpr bool is_scoped_enum_v = _Is_scoped_enum_impl<_Ty>;

[StephanTLavavej]

I would prefer to get us out of the business of writing increasingly arcane code to implement type traits. So:

• Using Clang's intrinsic is great.
• Requesting MSVC and EDG support for Clang's intrinsic would be a good idea.
• Adding complexity to is_scoped_enum's library-only implementation to handle corner cases involving MSVC non-conformance seems like the wrong direction, and a way to introduce novel bugs. Given that is_scoped_enum hasn't been causing trouble, I don't think we should do that.