Non-indexed map view for MSVC debugger

[cmakshin]

This update to the map visualizer shows the key in the name column and the value in the value column, just like std::map and proposed tsl::sparse_map (Tessil/sparse-map#5) visualizers do.

Also I moved the bucket visualizer to the end of the .natvis file in order to keep more important (containers > iterators > internal structures and helpers) parts of the file closer to the top for easier navigation and maintenance.

[Tessil]

I changed the natvis file a bit to match more closely what is done for std::unordered_map/set. It seems the specialization on hopscotch_bucket is not really necessary as if I let it as it is I get:

Name: ["Key1"] Value: ["Value1"]

instead of what std::unordered_map would show:

Name: ["Key1"] Value: ("Key1, "Value1")

Warn me if I made a mistake, otherwise I'll merge the changes to the master.

Thank you again for your contribution!

[cmakshin]

I'm OK with showing the key in the value column, I just don't see any good reason to do that when the key is already visible in the name column. :)

Also std::map visualizer shows only the value in the value column. What does make std::unordered_map (or any other key-value container) so special that its elements should be displayed in a different way? I don't know.
However, I think it makes sense to aim for consistency with std::unordered_map specifically.

[Tessil]

Yes I'm not really sure why Microsoft made this choice, as the difference between std::map and std::unordered_map is a bit weird.

But I prefer to keep the consitency with std::unordered_map instead of std::map. It also has the advantage of having some consitency on what we do with tsl::ordered_map.

I merged the changes, thank you.

[cmakshin]

The problem with tsl::ordered_map is that it IS special — actual key-value pairs are stored in a different container selectable through a template parameter. This detail makes it impossible to write a generic/universal non-indexed view for tsl::unordered_map.