(cfn-include): Handling parameters in a way that is less scary when migrating

Introduce a way of setting parameters, but in such a way that the diff doesn't make me scared when migrating existing Cloudformation stacks into CDK.

### Use Case

I have an existing production system deployed using Cloudformation with parameters, and want to bring it into CDK so I can write new code as CDK and throw away the old deployment tooling. And, where possible, manage changes to the old code through CDK (eg using `cfnTemplate.getResource`). And I think this will all work fine.

However, I pointed it at my yaml templates, set the parameters for each stack, ran cdk diff and was immediately terrified. There were lots and lots of changes because of clever CDK things setting parameters. I think all these changes are no-ops from what I have been able to manually review.

A small slice of the diff I see:
```
Parameters
[-] Parameter EnvironmentName: {"Type":"String","Description":"The name of the environment"}
...
Resources
[~] AWS::S3::Bucket mystack-include/BackupBucket BackupBucket replace
└─ [~] BucketName (requires replacement)
└─ [~] .Fn::Sub:
├─ [-] ${EnvironmentName}-backups
└─ [+] myapp-backups
```

Where the existing Cloudformation parameter `EnvironmentName` is set to `myapp`, and I've passed `parameters: {EnvironmentName: 'myapp'}` to `CfnInclude`. Is it going to try to delete that bucket and replace it? I think... no? It will fail to do so even if it does try, because there's stuff in the bucket, but hopefully this illustrates the source of my fear.

### Proposed Solution

Some options I can think of:
1. Bravery. Trust in the CDK's handling of these parameters to do the right thing.
2. Diligence. Manually verify all of the parameters will be change from: (a reference to a parameter that is set to X) to: (just X)
3. `cfn-include.CfnInclude` grow the ability to set parameters "the old fashioned way", which would match with what I am migrating into CDK using this module. I would expect this to then show nothing in the diff (with the exception of the CDK metadata stuff) which would no longer terrify me. I could then maybe switch the parameters over one-by-one to reduce my fear and to make the diff easier to understand, if I felt the need.
4. A hack. I have hunted for a way of forcing the parameters to my stacks to be the values I want them to be but not found anything. If I don't set them, then they don't complain and I guess use the values currently deployed in Cloudformation, which is ok, but means their values are not in my source control. And I can maybe set them with the command line, but I can't see a way of doing this when running diff, so am unsure. I was able to update the defaults for the parameters in the template, but I hate this because the parameter values actually set in Cloudformation will take precedence.
5. Trust Cloudformation changesets rather than cdk's diffs. Run synth, update the stacks with the outputs from that, review the changesets, verify they are no-ops (but for adding CDKMetadata) and execute. This is annoyingly manual, but I think is quite safe.

I would be fairly happy with any of those options except 2. And there might well be another way of handling this to change the synth behaviour around parameters that I don't know.

* [ ] :wave: I may be able to implement this feature request
* [ ] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

Start at CfnInclude's parameter handling and compare synthesized templates with cdk diff for the YAML-template case. Check whether an approach can preserve existing CloudFormation parameter references while allowing values in source control; done means migration produces no unexpected resource changes and only expected CDK metadata changes.

Written by the indexing model from the issue text.