Extract Data.Aeson.Compat

[Pat Brisbin]

This package contains a module to paper over some aeson-1.x vs 2.x differences. Specifically Key and KeyMap. We've since needed this in many other places, it seems like something that would be useful community-wide.

When we did it originally, we only didn't release it as its own package because one already existing with the name aeson-compat, doing a different thing. That package appears to be gone now, so we can use that name.

[Pat Brisbin]

I've started working on this, but I can't decide between two approaches:

1. Expose Data.Aeson.Compat modules
2. Expose Data.Aeson modules

With (1) users would need to add our package and import(s). They would have to be sure to use our modules, probably qualified, to avoid having redundant import warnings when aeson-2.x is present and Data.Aeson exposes some of the same types itself. This is less intrusive, but having to dance around a particular kind of imports feels counter to our intent of making it easy to operate with mixed-version aeson dependencies.

With (2) users would need to replace the aeson package and imports with ours. This is better ergonomics, as you can just import and use Data.Aeson{.Key,.KeyMap} normally and it'll Just Work in the presence of aeson-1.x or 2.x. But it would be harder to also use the aeson package at the same time (without, e.g., PackageImports), so if the user needs to do that for whatever reason, are we making it more harder for them than we are making it easier for the common case?

[Pat Brisbin]

After discussion with @chris-martin, we lean toward Data.Aeson.V2{.Key,.KeyMap}. This makes it explicit that we're offering compatibility for aeson-2-and-back. If/when aeson-3 comes out, we'd create Data.Aeson.V3{...} to support that.