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`](https://github.com/brendanhay/amazonka/blob/feature/waiters/core/src/Network/AWS/Types.hs#L382) 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`.

1. It might be worth investigating commonality between the waiter parameters to see if the smart constructor can alias the actual request/operation construction
2. Enforce invariants on the actual parameters since they are usually idempotent 'describe-like' actions requiring sets of ids or filters.
3. Create correspondence between the request/operation and the selection of the waiter, probably using type classes/families. Unfortunately this info [isn't available](https://github.com/brendanhay/amazonka/blob/feature/waiters/gen/input/ec2/2014-10-01.waiters.json#L4) in the specification and may need to be hand-rolled rather than inferred.

The `await` name was chosen to avoid clashing with `Control.Lifted.Async.wait` which I tend to personally use a lot in conjunction with this library. It clashes with `Data.Conduit.await`, and is potentially not the best name .. but bugger me if I cannot think of a better (meaning/succinctness) one currently.