Some design notes on this...

1. I think the differences between CfnGuard rules and Python Lambda rules are probably large enough to not reuse configRule.yaml and configRuleOrganization.yaml CFTs. Instead, we should split out configCfnGuardRule.yaml and configCfnGuardRuleOrganization.yaml.

2. We'll pretty much only need one resource for CfnGuard rules: the Config rule itself. Within this rule, the Source key will need the most updates. Owner will be set to CUSTOM_POLICY, SourceIdentifier will not be provided, and (because CfnGuard rules do not support Periodic evaluation) SourceDetails will always be set to an array of:

- ConfigurationItemChangeNotification
- OversizedConfigurationItemChangeNotification

And of course, we'd need to update the CustomPolicyDetails section with the rule text itself (maximum 10k characters). Not sure if any flattening/formatting is necessary in CustomPolicyDetails.PolicyText. Would need a Boolean for EnableDebugLogDelivery. And PolicyRuntime probably just gets hardcoded to guard-2.x.x.

There's probably some other minor changes like removing InputParameters keys.

3. configCfnGuardRuleOrganization.yaml will likely look similar.

4. Next question is what the user experience will look like...we'll definitely need new runtime templates generated, perhaps with some commented-out guidance on how to write CfnGuard rules. Fortunately, we won't need rdklib support since there's no Lambda. We'll just need a runtime like guard-2.x.x, and support that in commands like rdk create myGuardRule --runtime guard-2.x.x. The parameters.json file will likely be shorter, too. On the deployment side, we'll need to update and test deploy, deploy-organization, modify, undeploy, and undeploy-organization. For deploy, we'll still probably keep the behavior of uploading a zip of the policy to S3, but I could be convinced otherwise.

5. rdk.py will need someone to make the plumbing work to convert those new CfnGuard inputs into the outputs described in points 1-3. Not looking forward to that.