[RULES] Validate CloudFormation parameter overrides

**Describe the example rules**

The rules check that a set of CloudFormation parameter overrides conform to the new (v2) JSON format for parameters.
If a parameter value contains an ARN, it is checked for correctness via regex.

Edit: The goal of this rule is to shift-left when ARN values are provided as CloudFormation parameters. If parameters represent an ARN but are malformed, it will pass the initial changeset creation but will then fail. This example was driven from a practical requirement where users were managing complex CloudFormation stack parameter JSON documents in Git and wanted a way to apply quality control very early on.

**Ensure you meet our example rules submission policy**

1. Do not mention any security or compliance regimes in custom messages, file names, rule comments, etc. Example rules are purely for educational purposes and cannot be represented as providing any kind of certification for control regimes like CIS, GDPR, etc [confirmed]
1. Rules should not be duplicates. Please grep the Examples directory contents to ensure that the rules are not already present in another rules file. [confirmed]
1. Rules must include comments or custom messages that describe the function of the rule. [confirmed]
1. If you are adding new rules to an existing rules file, be sure to update the corresponding tests file (YAML file with the same file name prefix) with test inputs which help understand the rules your adding. [N/A]
1. If you are adding a new rules file, be sure to include a corresponding tests file with test inputs which help understand the rules present in the rules file you are adding. [confirmed]
1. The preferred file system structure is:
1. **Examples/-tests.yaml**
1. **Examples/.guard**

Meaningful file names can include AWS resource types, types of checks being done (e.g. “check-lambda-function.guard”), etc.
1. Test your rules by running them against the corresponding tests file. Your pull request description must include a markdown-formatted code block showing the result of your test run (not the logs - just the basic output). [confirmed, see below]
1. Rule file names, rule descriptions, etc. should not make mention of the contributor’s identity. (The connection will already be established by merging the commits.) [confirmed]

**NOTE: Please be sure that the templates, rules and logs you provide as part of your bug report do not contain any sensitive information.**

**Additional context**

```unix
cfn-guard test --rules-file check-wellformed-parameters.guard --test-data check-wellformed-parameters-tests.yaml
Test Case #1
Name: "DoesNotApplyToEmptyFiles"
No Test expectation was set for Rule has_likely_valid_arn
PASS Rules:
has_correct_keys: Expected = SKIP, Evaluated = SKIP

Test Case #2
Name: "FindsRequiredKeys"
PASS Rules:
has_correct_keys: Expected = PASS, Evaluated = PASS
has_likely_valid_arn: Expected = PASS, Evaluated = PASS

Test Case #3
Name: "FindsMalformedArn"
PASS Rules:
has_correct_keys: Expected = PASS, Evaluated = PASS
has_likely_valid_arn: Expected = FAIL, Evaluated = FAIL

Test Case #4
Name: "ChecksForMissingKeys"
PASS Rules:
has_correct_keys: Expected = FAIL, Evaluated = FAIL
has_likely_valid_arn: Expected = SKIP, Evaluated = SKIP
```

Add any other context you think is relevant here.

Review Examples/check-wellformed-parameters.guard and its matching check-wellformed-parameters-tests.yaml, then run the cfn-guard test command shown in the issue. Done means the four listed cases produce the expected PASS, FAIL, and SKIP results for has_correct_keys and has_likely_valid_arn.

Written by the indexing model from the issue text.