Gen cabal template

[endgame]

I was talking with a colleague about the generator today. I think one of the big reasons the generator is hard to untangle is that many of its types are pulling double or triple duty: first, they represent the JSON files are they are read in from botocore (and merged with our annexes); second, they represent the service as the generator understands them (as a service with endpoints and operations that send/receive shapes in formats); third, they represent (via their ToJSON instances) the input to the various .ede templates used to generate the output files.

I hope to eventually deal with #888 by starting at the output and refactoring backwards, until the types currently in amazonka-gen aren't participating in output any more. This PR is the first step in that plan. It introduces the Gen.Output namespace and a Gen.Output.Template.Template type, representing a template that tracks the type of the record it needs to consume. Gen.Output.Template.CabalFile then represents the fields needed by cabal.ede, and its only job is to get them into the HashMap Text Aeson.Value that EDE requires.

This then revealed some easy opportunities for simplification, so I did them too.

The hope is that once the current types are no longer overloaded, we can simplify them by removing type variables, instances, etc., and eventually replace them (e.g., by replacing the cofree comonadic shape functor with a type that only refers to shapes by name; when everything looks at it from that perspective, #888 becomes impossible).

The current goal is to have three phases — "input", "model", and "output":

• "Input" should read the source IDL as accurately as possible. Currently this is botocore and we have https://github/bellroy/hs-botocore to eventually swap in here;
• "Model" will be our playground to describe AWS services. I expect this to be aware of request and response shapes, but also Haskell-specific things like what types to use in a representation, which deriving clauses we need to generate, and which module names to import (and whether to import them {-# SOURCE #-} or not); and
• "Output" will be where we set up the output directory tree, feed data to EDE templates, etc. Because each template will eventually have its own record to track its inputs, we may want to include a thin layer of type-safety here. Future work might have an argument record contain a [ModuleName] naming the exposed-modules instead of a [Text], but the main point is to keep this as simple as possible.

This PR does not change the output of the generator at all; I re-ran it over the repo and got a clean diff.