Use struct tags to aid in static validation

[mbarnes]

What this PR does

This adds a dependency on github.com/go-playground/validator, which is an interesting way to implement static validation through struct tags.

This doesn't fully cover static validation, but helps remove some of the potential tedium of hand-written validation checks.

This also beautifies cloud error responses due to validation errors. Here's an example from some test data:

$ curl -X PUT http://localhost:8443/subscriptions/SUBSCRIPTION/resourcegroups/RESOURCEGROUP/providers/Microsoft.RedHatOpenshift/hcpOpenShiftClusters/mbarnestest?api-version=2024-06-10-preview --json @cluster.json
{
    "error": {
        "code": "InvalidRequestContent",
        "message": "Content validation failed on one or more fields",
        "details": [
            {
                "code": "InvalidRequestContent",
                "message": "Invalid value 'invalid' for field 'provisioningState' (must be one of: Canceled Failed Succeeded)",
                "target": "properties.provisioningState"
            },
            {
                "code": "InvalidRequestContent",
                "message": "Invalid value 'this_is_not_a_cidr_address' for field 'podCidr' (must be a v4 CIDR address)",
                "target": "properties.spec.network.podCidr"
            },
            {
                "code": "InvalidRequestContent",
                "message": "Invalid value 'private_eyes_they're_watching_you' for field 'visibility' (must be one of: private public)",
                "target": "properties.spec.api.visibility"
            },
            {
                "code": "InvalidRequestContent",
                "message": "Invalid value 'this_is_not_a_url' for field 'issuerUrl' (must be a URL)",
                "target": "properties.spec.issuerUrl"
            }
        ]
    }
}

Jira: ARO-5736: Create static validation for frontend API Structs

(I started working on ARO-6347: Validate metadata from api structs but this ended up falling more into ARO-5736)

Special notes for your reviewer

Please read the individual commit messages, some of which have additional detail.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Deployment: The deployment process was considered and addressed if required
• Testing: New code requires new unit tests.
• Documentation: Is the documentation updated? Either in the doc located in focus area, in the README or in the code itself.
• Customers: Is this change affecting customers? Is the release plan considered?