Update generated services, remove generated lenses, and various miscellaneous generator fixes

[brendanhay]

Summary of changes

• Continues the work started by in #169. (Thank you, @madjar!)
• Exports all types data constructors + fields.
• Hides some of the serialisation related wrapper types (such as Textual) by embedding their use directly into the related serialisation instances, ie. {To,From}JSON . This allows the OpenAPI (type, format) tuple to correctly handle {u,}int64 and similar numeric types that are encoded as "type: string". There is further work still to do here, primarily around date/time related types, to make using the now fully exported data constructors more palatable in the cases custom de/serialisation of fields is required.
• Generated code now uses fully qualified imports for non-local package imports to make the packages more robust to dependency upgrades.
• Sum types are now emitted as pattern synonyms to prevent de/serialisation issues and allow forward compatibility with service definition updates.
• Adds basic nix flake support for development with nix develop .
• Removes stylish-haskell - all {non,}generated code is now formatted using ormolu.
• Drops support for GHC 8.2.2 and 8.4.4 to ease maintenance. Support for GHC 9.0.2 has been added.
• A per-service package flag no-field-selectors has be added which defaults to True and will enable the GHC >= 9.2.1 NoFieldSelectors extension, if supported.
• Regenerates all the currently supported services, ie. those that were already being generated. New services will be considered for generation once this work has stabalised.
• Data types that are "floated" (via Flatten.hs, naming, I know) out of nested JSONSchema properties are now named according to <parent>_<property>. Previously a schema like "Location": { "properties": { "metadata": { "type": .. } } } would've synthesised LocationMetadata, which is potentially ambiguous, so now the generator will produce Location_Metadata.
• Resource data types are now fully qualified according to their id. For example, { "resources": { .. { "id": "storage.buckets.insert" } which would previously have floated data BucketsInsert in Network.Google.Storage.Buckets.Insert, will now float data StorageBucketsInsert in the same namespace. Again, this removes an additional source of ambiguity from code synthesis.
• Adds support for aeson >= 2.0.
• Removes the long deprecated ListT instances.

Moving forward

• Continue trimming off the unnecessary serialisation related wrapper types.
• Rework the build system to match amazonka, drop stack support, and enable GitHub actions.
• Rework the HasScope and scope related nonsense.
• Add support for new services. The generator now emits how many missing configurations were skipped, as of writing we're at 272 generated, 104 skipped.

[brendanhay]

A note on naming of (product) smart constructors and (sum) pattern synonym accessors:

• The original PR used mk as the prefix for smart constructors. I changed this to new to be consistent with amazonka at the cost of having to disambiguate some record fields like newPrice in gogol-android-publisher.
• To continue the consistency with amazonka, the pattern synonym newtypes for sums uses from<Name>.

This is mildly unfortunate, probably it would've been better to use mk / un as the prefixes since we'd likely never have to special case anything, but I hope for the day we can just pervasively enable NoFieldSelectors and not deal with this.

[brendanhay]

Closes #169

[sternenseemann]

Can we get a new release to hackage with these changes included. A lot of useful fixes have accumulated on the main branch by now, including ones I believe should allow compiling with the new Stackage LTS 19 snapshots.

[tonyalaribe]

It appears the docs for the new types don't reflect on hackage. It's not clear to me how the fields should be used, since the old lens accessors don't work anymore