<flat_meow>: Implement natvis visualizers for flat_multimeow, simplify visualizer for flat_map

[vmichal]

Revisit natvis definitions for flat_meow: remove unnecessary special cases for flat_map without changing the visualization.

• Use the same visualizer for flat_(multi)set
• Remove all special cases for flat_map and merge them into a single definition.
• Use the same visualizer for flat_(multi)map

Towards #5950

[vmichal]

I have updated the fallback visualization of std::flat_(multi)map to at least show size, which calls _Data.keys.size() (there should be no problem parsing that, as we use it in our implementation).

Should the main visualization for std::flat_(multi)map fail, it would be more likely because of the use of operator[] on key and mapped containers. We don't actively use these functions in <flat_map>, so I can imagine a world where the user specializes std::flat_(multi)map with a container that lacks operator[] and has random-access iterators.

[vmichal]

Just to clarify the intent of multiple PRs: The visualization of <flat_meow> data structures will additionally improve by accepting two other loosely related changes

• Consistent visualization of comparison objects proposed in STL.natvis: Add visualizers for ranges::less and other comparison objects. #6016
• Harmonization of other iterators (mostly vector, but for consistency it also changes very similar array and span) and the visualization of their end() state STL.natvis: Harmonize visualization of _Vector_iterator and _Array_iterator, properly visualize end() _Vector_iterators and _Span_iterators when _ITERATOR_DEBUG_LEVEL != 0 #6019

These changes are self-contained, so I extracted them from feature branch and opened a PR to main. There are no adjacent-edit conflicts.

[StephanTLavavej]

Wonderful, thank you! 😻