feat: Support environment variables for parameters and deploys in rain deploy

[rtkjbeverly]

Issue #: #711

Description of changes:

Support sourcing parameters and tags for rain deploy using prefixed environment variable names.

This change adds support within the rain deploy command for sourcing values from environment variables. Parameters will be sourced using any variable with a prefix of RAIN_VAR_ and RAIN_DEFAULT_TAG_* for tags.

# Set CloudFormation parameters 'VpcId' and 'Environment'
export RAIN_VAR_VpcId=vpc-xxxxxxx
export RAIN_VAR_Environment=perftest

# Set CloudFormation tags 'Environment' and 'Owner'
export RAIN_DEFAULT_TAG_Owner=$USER

# file: template.yaml
# Parameters:
#   InstanceType:
#     Type: String
#     Description: EC2 instance type
#     Default: t3.micro
#   Environment:
#     Type: String
#     Default: dev
#   VpcId:
#     Type: String

# Deploy with Rain (environment variables are automatically picked up)
rain deploy my-stack template.yaml

---

Testing
Confirmed with the addition of new unit tests that all tests are passed.

Exploratory tests performed on the branch are:

• No environment variables for standard deployment flow. Confirmed no tags or parameters passed.
• The setting of tags using environment variables. Confirmed tags applied, no parameters passed.
• The setting of tags and parameters using environment variables. Confirmed tags and only applicable parameters impacted.

Additional Notes

• For environment naming, I went with RAIN_ as prefix for the tool, then VAR and DEFAULT_TAG as that was what the internal wrapper scripts this feature is based on used. You can see Support rain deploy sourcing parameters & tags from environment variables #711 for a simplified example of this script. DEFAULT_TAG could be renamed to STACK_TAG or something else to better reflect its the tags of the stack, and not modifying the template in anyway.
• Some of the logs use config.Debugf while others use fmt.Print, I just tried to copy whatever kind of worked, but if we should shift them to standard logging, that works.

[rtkjbeverly]

I only re-generated this specific file as it changed, and didn't want to include the 19-Nov change for everything.

If you'd like I can rerun it for all.

[rtkjbeverly]

This could be simplified to just return messages whenever an override happens, regardless of the source. But I figured I should be more explicit in the diagnostic messages, to avoid obvious cases where someone doesn't realize one of the 3 sources of variables could be conflicting.

[rtkjbeverly]

Nothing prevents these from being RAIN_TAG_, RAIN_PARAMS_, or anything like that.

In fact it might make sense to rename them to RAIN_TAG_ & RAIN_PARAM_ to align with the command line arguments & config file fields.

But I'm preserving the naming pattern from the original helper seen within the GitHub issue. I'm fine with any option the maintainers want to see for ensuring better user experience.