Organize tests based on components rather than issue numbers

[AlexGuteniev]

Like LLVM tests.

This helps assessing coverage, executing tests in nearby areas.

Issue numbers can present in tests as plaintext, if needed.

[StephanTLavavej]

Thanks for the suggestion - we were able to talk about this at the weekly maintainer meeting. Thoughts:

• Fine-grained vs. coarse-grained tests are orthogonal to this organization question. libcxx happens to be both fine-grained and component-organized but there's no inherent tie between the two. For various reasons (including the large size of our compiler configuration matrices), we prefer fairly coarse-grained tests (e.g. all of vector instead of each individual member function or even group of member functions).
• We wouldn't want to perform a large-scale reorganization of existing tests immediately, as that would be a lot of disruptive work for relatively little benefit. If we try the new organization system for new tests and become comfortable with it, we can explore incrementally converting older tests as it makes sense (and some old tests cover so many different components that they'll always be strongly resistant to such organization).
• Having component-organized tests located under tests/std/tests/SOMETHING would be reasonable (I jokingly suggested tests/std/tests/std 😹 but we probably don't want that), and from there, use Standard stable names (as libcxx does), since they can be easily navigated and change rarely.
• After new tests are added in such a path, I'll mention this in the long-awaited Contribution Guidelines so new contributors and maintainers can learn about this new system.

[AlexGuteniev]

Turns out we don't want this. It is easier to follow the existing practice than establish a new one.

Note also #5370 vector<bool> benchmark movement

[StephanTLavavej]

Agreed, I forgot about this, and have no interest in it anymore. The existing system works.