Explicit wait logic for specific service states

This PR is the final piece to close #25.

It parses the relevant service's `<service>/<version>.waiters.json` if present, and generates `Wait a` constructors per specification under a library namespaced `Waiters.hs` module.

For example, EC2: [specification](https://github.com/brendanhay/amazonka/blob/feature/waiters/gen/input/ec2/2014-10-01.waiters.json) -> [Network.AWS.EC2.Waiters.hs](https://github.com/brendanhay/amazonka/blob/feature/waiters/amazonka-ec2/gen/Network/AWS/EC2/Waiters.hs)

All smart constructors are exported by the service interface - `Network.AWS.EC2` in the above example.

These `Wait a` types can then be explicitly used with the new [`await`](https://github.com/brendanhay/amazonka/blob/feature/waiters/amazonka/src/Network/AWS.hs#L149) primitives in the top-level `amazonka` library to perform retries according to the specification (mirrored Monad Transformer variants are available).

Usage would be something like:

```haskell
-- Wait for specific bundling tasks to be completed.
-- According to the bundleTaskComplete waiter which is
-- maximum 40 attempts with 15 second retry intervals.
await bundleTaskComplete (describeBundleTasks & dbtBundleIds .~ ["1", "2", ...])
```

This is obviously not ideal - the constraint between the `Wait a` specification and the construction of the request is 'loose' in the sense the user must still construct the request fully, as a secondary parameter to `await`. It might be worth investigating commonality between the waiter parameters to see if the smart constructor can mirror the actual request/operation construction, or enforce invariants on the actual parameters since they are usually idempotent 'describe-like' actions.

**TODO**

* The actual acceptance criteria/check for the responses, the index notation needs to be parsed and rendered accordingly.
* Documentation