Short-circuit some variant constraints

[CaseyCarter]

variant's converting constructor and assignment operator templates are constrained to reject arguments of the variant's type. In such a case, the templates instantiated to check the constructibility constraint might be ill-formed outside the immediate context of template instantiation causing a hard error. We should split the constraints into multiple enable_if_ts to enable short-circuiting of later constraints when the earlier constraints fail.

Fixes #4959.

[CaseyCarter]

I'm open to suggestions on improving the formatting of these enable_if_ts. Nothing I tried looked significantly better than what clang-format produces.

[barcharcraz]

Is there a way to stop it from aligning the = 0s? That's the only somewhat ugly thing going on here.

[CaseyCarter]

Other than clang-format off, our normal trick is to add a blank line breaking consecutive lines with = so clang-format won't align. Would a weird blank line in the middle of the template head be better or worse:

        enable_if_t<sizeof...(_Types) != 0 && !is_same_v<_Remove_cvref_t<_Ty>, variant>
                        && !_Is_specialization_v<_Remove_cvref_t<_Ty>, in_place_type_t>
                        && !_Is_in_place_index_specialization<_Remove_cvref_t<_Ty>>,
            int> = 0,

        enable_if_t<is_constructible_v<_Variant_init_type<_Ty, _Types...>, _Ty>, int> = 0>

[StephanTLavavej]

I like the idea of having a blank line here, it seems to be the least of all evils and it kind of helps with the readability of the bulky SFINAE conditions.