Move to AWS v3 library

[jjlimepoint]

As the world turns, so do library versions. Move to AWS v3 - note that this has ONLY been tested on my integration test rig, which means only ec2 / custom networking / vpc, s3, and elb have been tested, however I'm pretty confident in the safety given that those required no changes beyond the gemfile.

That said, I did bump the major version since v3 aws is a major change that affects gem dependencies. It would work as v2/v3 allowed, if we wanted to do that, though I haven't done that in this PR due to test coverage issues (I wanted something testable in my environment...)

It probably depends on the PR for provisioning being removed from DK, since DK uses aws v2 (though their PR says they want to use v3 as well, and prov-aws is holding them back, so shrug)

Someone other than me should probably test this before merging :)

[jjlimepoint]

Updated to not hard require v3, but rather allow it as an option, and remove some cruft comments that I added to the patch

[tas50]

Looks like you can squash this down to a single commit. There's also some Travis failures going on.

[jjlimepoint]

@tas50 both facts - the travis one caught a corner case which I had not. huzzah for tests. (also squashed now)

[tas50]

@jjlimepoint I'd really like to migrate this gem to the V3 library, but I'd like to make sure we use the individual gems instead of the monolithic gem. There's a lot of code we can shed off if we move to the appropriate v3 gems. Is that something you want to tackle or should I close this out and take a stab myself?

[jjlimepoint]

I can do that tomorrow most likely - I mostly avoided it initially in a vain attempt to maintain v2 compatibility - but i'm not super inclined to care about support for v2 if no-one else is!

[tas50]

I'm working to get V3 into kitchen-ec2 and we'll need to do the same thing with inspec. It requires all 3 to land at the same time. Total pain, but we have to do it sometime.