[Resolves #961]: Hook.stack is not necessarily the stack actually being updated

[gilleswijnker]

[Resolves #961]: Hook.stack is not necessarily the stack actually being updated.

Please note this request introduces a breaking change for custom Hooks. Hook.stack has been removed. Hook.run now accepts a single parameter stack.

PR Checklist

• [ X ] Wrote a good commit message & description [see guide below].
• [ X ] Commit message starts with [Resolve #issue-number].
• [ X ] Added/Updated unit tests.
• [ NA ] Added/Updated integration tests (if applicable).
• [ X ] All unit tests (make test) are passing.
• [ X ] Used the same coding conventions as the rest of the project.
• [ X ] The new code passes pre-commit validations (pre-commit run --all-files).
• [ X ] 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

[ykhalyavin]

@zaro0508 could you please review? In our work we have some hooks where we have to execute certain boto3 calls after the stack A is deployed and we need to pass to our hook X outputs from the stack A (work with TGW) and this PR straightens our workarounds

[zaro0508]

thanks for the contribution however I don't think we can break every Sceptre custom hook out in the wild. I would prefer a more general solution that would allow hooks or resolvers to access the stack object.

If this is the only solution then i think it would need to be done with a new interface and then deprecating the old one.

[alex-harvey-z3q]

@gilleswijnker @ykhalyavin Is it ok for me to close this PR?