Refactor handling of CFn stack parameters

[dominikschubert]

Changes

• Parameters are resolved only once when executing CREATE/UPDATE tasks. While the corresponding logic lives in parameters.py now, the responsibility is moved further up to the API provider to make this as transparent as possible.
• Unifies parameter resolving (previously this was done in multiple places such as in Stack methods, template_processing, transformations, template deployer)
• Update handling is now more robust and simpler.

What hasn't changed

• Does not affect how parameters are used when resolving values/refs in the TemplateDeployer/Stack, i.e. they are still merged with resources and mappings/conditions in Stack.resources for now. This will be split up in a future PR.
• No new parameter types have been added

Also note I didn't add further tests yet since I didn't want to bloat this too much. I've started on more parity focused tests but I want to give them a bit more polish and build a proper parameter test suite out of it first.

[github-actions]

LocalStack Community integration with Pro

2 084 tests   1 803 ✔️  1h 27m 40s ⏱️
       2 suites     281 💤
       2 files           0 ❌

Results for commit 463a380.

♻️ This comment has been updated with latest results.

[dominikschubert]

I didn't see much of a value at this point for these resolve unit tests since I'd prefer to use proper integration tests here soon.

[coveralls]

coverage: 82.732% (+0.01%) from 82.721% when pulling 463a380 on refactor-cfn-resolve-parameters into 30f2123 on master.

[simonrw]

Excited to move this piece of the process to its proper place - before the template deployer gets created 👍

[simonrw]

It's nice to not have to deal with parameters in the deployer itself!