Add _STD to improve tuple throughput

[StephanTLavavej]

Our recursive tuple implementation is a challenge for compiler throughput. By profiling the compiler, @xiangfan-ms identified something that we were previously unaware of. Name lookup within enable_if_t constraints can be expensive in certain situations (enormous tuples, where the recursive inheritance and pack expansion lead to quadratic behavior within the compiler, combined with permissive mode). This affects the names of structs/classes, but doesn't affect alias/variable templates for a reason which was novel to me - struct/class names become injected-class-names, so the compiler remembers that they can be member names, but alias templates and variable templates aren't declared as member names. Within a large tuple with many bases, name lookup for is_meow has to consider whether it could be an injected-class-name (which will consider the many base classes in permissive mode), but name lookup for is_meow_v can be optimized because the compiler knows that it has never been seen as a member.

This is significant enough to motivate an exception to our usual convention, where we don't use _STD qualification for non-functions (because only functions are vulnerable to ADL). I've gone through <tuple> and looked at each of its enable_if_t constraints, and I've marked all of the mentioned structs/classes as _STD (including tuple itself when forming another specialization). I didn't bother modifying the !_HAS_CONDITIONAL_EXPLICIT codepaths (they are used for CUDA only, and hopefully not forever). Also, plain tuple still refers to the tuple's own injected-class-name; AFAIK this is not a bottleneck (because it should be found immediately, preventing any lookup into base classes in permissive mode).

[StephanTLavavej]

@xiangfan-ms has profiled this PR and confirmed that it improves tuple throughput, especially when there are more than 50 or so template arguments. (100-ish arguments have been encountered in real world code.) Also, there are no observed throughput regressions even for smaller tuples (32 args was observed to be sped up from 299 ms to 290 ms).

[CaseyCarter]

Just a request for more documentation.

[StephanTLavavej]

Thanks again for writing the explanation here, @CaseyCarter - it's the difference between a good codebase and an excellent codebase. 😻