[Partially Resolve #1193] Automatically adding Sceptre tags to all stacks

[jfalkenstein]

This PR adds some basic Sceptre stack metadata to every stack, namely:

• sceptre_name: This is the "sceptre name", that will look like "outer-stack-group/inner-group/stack-name". Regardless of whether the real stack's name has been set via the "stack_name" attribute or automatically by Sceptre by default, this name will be consistent with the actual directory/StackGroup structure of the sceptre project that launched it.
• sceptre_project_code: This is the project_code of the sceptre project that launched the stack.

This is the first step toward accomplishing the goals of #1193, namely providing the means for Sceptre to locate stacks that were previously associated with the project but whose stack configs have been deleted. We will need further code changes to fully implement #1193, but they will build on these changes.

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]

should we follow the cloudformation convention of using a <prefix>: ? https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html

so something like sceptre:name and sceptre:project-code?

also, aws tags have limitations so maybe we should check for them? https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html (Tag naming limits and requirements)

[jfalkenstein]

should we follow the cloudformation convention of using a : ? https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html

Yeah, that sounds good to me, actually. That's an easy change.

also, aws tags have limitations so maybe we should check for them? https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html (Tag naming limits and requirements)

That's a good point. While I don't think it's very likely that we'd hit the 256 character limit on values or infract upon the allowed character limitations, we could indeed validate and even coerce those values to conform to those limits.

[jfalkenstein]

Looks like there are a number of integration tests I'm going to need to address on this one.

[jfalkenstein]

I'm going to close this PR. I think the delete flag will be more appropriate of a solution. There's a real problem with the approach this PR was intending to allow; there's a massive amount of boto3 requests required to have certainty about which stacks have been abandoned.