Allow parameters to be specified on managed custom org policies

[Jberlinsky]

Description

Fixes #92, see that issue for additional context.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Deployment & Compliance Impact

• Applicable Regimes:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Moderate
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • General / All
• NIST 800-53r5 Controls: (If this PR helps satisfy or modifies control implementations, list them here)

Checklist

Code Quality & Reusability

• My code adheres to the Maximize Reusability principle. I have not redefined common elements and have reused existing base configurations and modules where possible.
• I have checked that no existing module or configuration in modules/ or fast/ can be leveraged for this change.
• My code follows the established naming conventions outlined in documentation/naming-convention.md.

Documentation

• I have updated the README.md of the modified module or blueprint.
• I have added/updated documentation for inputs (variables) and outputs.

Security

• My change adheres to GCP security best practices and the principle of least privilege.
• I have ensured compliance with the targeted regime (FedRAMP High, IL5, etc.).

Testing

• I have tested my changes locally.
• I have included details of my testing in this PR.

Testing Performed

Modified fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml as follows:

...
 essentialcontacts.managed.allowedContactDomains:
   rules:
   - enforce: true
-
+    parameters:
+      allowedDomains:
+        - "@NEW_DOMAIN.COM"
...

After execution, ensured that the Org Policy UI in Pantheon accurately reflects NEW_DOMAIN.COM, and creating an Essential Contact @NEW_DOMAIN.COM succeeds where it previously failed.