yaml: add option for using Maps instead of objects for mappings

[KevinMGranger]

Is your feature request related to a problem? Please describe.

JS objects are limited to string and symbol keys. If one needs different key types, there's Map.

YAML is capable of mappings that have non-string keys. It's a niche use case, sure, but one I have! I'm using number keys to map events that trigger at certain milestones in my data model:

milestones:
  3: A3
  6: D4
  9: G3

Right now, I have to re-parse the numbers and convert it into a Map. An easy one-liner, but unnecessary IMO!

Another ugly use case that I don't personally have, but I guess is valid

I hope one never does this, but...

mapping:
  2: technically
  "2": valid 😔

Describe the solution you'd like

Add a boolean option to ParseOptions, useMaps, defaulting to false.

Describe alternatives you've considered

Just putting up with converting the objects 🤷

[tomas-zijdemans]

Opened #7290 implementing this behind a useMaps boolean on the unstable parse(), per the request.

Two adjacent questions for maintainers that I deliberately kept out of that PR:

1. Stable stringify(new Map([["a", 1]])) silently emits {} today, which loses data. feat(yaml/unstable): add useMaps option to parse mappings into Maps #7290 fixes this only in the unstable stringify(). Should the stable one learn the same representation (a behavior change), or throw TypeError like other unrepresentable values do?
2. Longer term, for 2.0: should default object mode turn the "[object Object]" key coercion into a YamlSyntaxError that names useMaps, instead of silently mangling non-string keys?