Test: Concept "archetype" test readability is poor

Many (all?) of the tests for standard library concepts have an archetype model in which one or more types are parameterized on an integral value. That value selects precisely one of the concept's requirements which the archetype will then violate. We then have either a sequence of static_asserts (or something more template-y where one function template calls another in a fold expression over an index sequence because Casey never met a problem that couldn't be solved with more complicated metaprogramming) that e.g. archetype<42> satisfies the concept but all specializations with a parameter lower than 42 do not.

Testing-wise this is all great, but the readability of these tests is poor. The mapping between parameter values and requirements is either undocumented and must be derived by scrutinizing the code or scattered around in comments // 11: don't satisfy frobnicate. If we could devise a way to encode these mappings in (probably scoped) enumerations with descriptive enumerator names, it would help tons.

Start by surveying the standard library concept tests that use parameterized archetypes and trace how each integral value maps to a violated requirement. The work is complete when those mappings are represented with descriptive, likely scoped enumerations and the tests remain behaviorally equivalent and easier to read.