[Resolve #1114] Project Dependencies WIP: Identifying stack as project dependency

[jfalkenstein]

This PR is on hold

In discussion with @zaro0508 and @zxiiro, we decided this aspect of addressing #1114 would be put on hold until the resolver work is finished.

This is the Fourth in a series of pull requests that addresses #1114 , allowing Sceptre to manage its own dependencies.

In this PR:

• Stack Configs can be marked with is_project_dependency: True. This is important, as it allows us to bypass the irreconcilable issue of multiple project dependency stacks depending on each other. With is_project_dependency: True, it will have the effects of:
  • Disabling all dependencies on that stack. They cannot be set on the current stack and they can't be inherited from parent StackGroups. In other words, a "project dependency" stack is automatically at the top of the dependency hierarchy.
  • Disabling the StackOutput resolver. It will "resolve to nothing" on project dependency stacks (see below). This means that it can be safely inherited from a StackGroup, but it won't actually do anything.
• Resolvers that return None "resolve to nothing", being removed from their container, just like "AWS::NoValue" does in CloudFormation templates. This prevents issues like when every stack in the project "inherits" template_bucket_name: !stack_output bucket.yaml::BucketName, and that would include the bucket.yaml stack, which cannot rely on itself.

• 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