[Resolve #1212] Conditional Stacks via "ignore" and "obsolete"

[jfalkenstein]

This feature adds two new Stack configurations, a new option on launch and a new command (prune):

• ignore will cause the launch command to completely ignore the Stack; It will be neither created, nor updated, nor deleted. If the Stack currently exists on AWS, it will stay as it is. If the stack does not exist on AWS, it will not be created.
• obsolete stacks function like ignored. ones, but will be deleted when pruned (see below)
• The launch command now has a --prune option. When launch --prune is invoked, all obsolete stacks on the command path will deleted first before the rest of the deployment proceeds.
• The new prune command will delete all obsolete stacks in the entire project (irrespective of any command path). This is a simple way to clean up potentially multiple stacks that need to be deleted.

This PR adds the feature described in #1212 and addresses the spirit of #1193 .

The basic idea here is you could do something like:

template:
    path: my/test/resources.yaml

{% if not var.use_test_resources %}
# If we set obsolete: True, it won't be created and will be deleted if it exists when launched with --prune
obsolete: True
{% endif %}

This feature addresses two needs:

1. The ability to selectively exclude Stack Configs when you run sceptre launch when it isn't ready or certain Jinja Logic determines that it should not be launched.
2. The ability to delete stacks as a part of a CI/CD process when they aren't needed/wanted any more.

PR Checklist

• Wrote a good commit message & description [see guide below].
• Commit message starts with [Resolve #issue-number].
• Added/Updated unit tests.
• Added/Updated integration tests (if applicable).
• All unit tests (make test) are passing.
• Used the same coding conventions as the rest of the project.
• The new code passes pre-commit validations (pre-commit run --all-files).
• The PR relates to only one subject with a clear title.
  and description in grammatically correct, complete sentences.

Approver/Reviewer Checklist

• Before merge squash related commits.

Other Information

Guide to writing a good commit

[zaro0508]

I'm not sure I agree with this approach therefore I have left reviewing the details until we can flush it out a bit more.

[alex-harvey-z3q]

@jfalkenstein approving on the basis that I don't have any objection to it and can't see any issue with it after reading your excellent docs and a once over read of the code without fully understanding it!

[zaro0508]

generally LGTM, just one more minor request and i think we are good to go.