add handling for plan when cfngin_bucket does not exist

[ITProKyle]

Summary

Using runway plan (with CFNgin modules) in a new environment can create a situation where the S3 bucket used to stage CFN templates has not been created yet. Being a planning step, we want to avoid creating an S3 bucket because the user may not consent to/expect it to be deployed and may intend to deploy it as a dedicated stack.

If the S3 bucket does not already exist, Runway will now log that it will be created during the next deploy (assuming it's not being created as its own stack) and proceed without using an S3 bucket.

This does introduce another case where the template may be too large to use directly with the API. If this is the case, Runway will log that an error occurred, skip the stack who's template was too large, and continue onto the next step.

NOTE: There was an issue uncovered while writing tests for this update and an issue was created to address it (#432).

Why This Is Needed

runway plan fails for CFNgin modules when the cfngin_bucket does not exist (closes #424).

What Changed

Added

• added a backport for http.HTTPStatus (part of the standard lib in python >= 3.5)
• added a class to simplify working with S3 buckets & AWS responses
• added handling for "template too large" error when planning a CFNgin deployment without an S3 bucket
  • informs the user that an S3 bucket is required

Changed

• when running runway plan, CFNgin modules will now skip using a cfngin_bucket if it does not exist
  • logs that it will be created during the next deploy
• the stacker shim is now in runway.module.cloudformation
  • it's previous location was causing a cyclic import when importing from runway.core in runway.cfngin

[ITProKyle]

@troyready - any ETA on when you may have a change to take a look at this? There are some sensitive areas it's touching (like the shim) and I want to make sure I didn't miss something.

There are some undesirable side effects (as noted in #432) that look to impact direct imports (outside of deploy/destroy) to some locations in runway but not all. Theres no real way to fix this without moving things around a bit which would likely constitute a major change.

I could temporarily relocate this addition inside of runway.cfngin until then which may mitigate the issue but that would create more work in the upcoming major release.

We could also postpone this until v2.