Azure Application Gateway WAF Policy REST and CLI have misspelling of the word "Condition" in negationConditon in Custom Rule

### Describe the bug

When we run az network application-gateway waf-policy show, and when we see the REST Docs: they use a field negationConditon to indicate that the condition should be inversed as a boolean.

See here: https://learn.microsoft.com/en-us/rest/api/application-gateway/web-application-firewall-policies/create-or-update?view=rest-application-gateway-2024-05-01&tabs=HTTP#matchcondition.

the field name "negationConditon" is misspelled and on that REST document page its description does spell "Condition" properly.

When we review the PowerShell implementation - the spelling is correct: https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/configure-waf-custom-rules#create-the-application-gateway.

When AzureCLI expects a custom object for this field, I think that there may be some mistranslation of the object that the Azure CLI method expects to what the REST expects, possibly exacerbated by the misspelling.

this is the output of the show command and this aligns w/ the REST docs so it appears the CLI returns what the REST team provides
`"customRules": [
{
"action": "Allow",
"matchConditions": [
{
"matchValues": [
"/_framework/icudt_EFIGS.dat"
],
"matchVariables": [
{
"variableName": "RequestUri"
}
],
"negatonConditon": false,
"operator": "Contains",
"transforms": []
}
],
"name": "test-custom-rule",
"priority": 10,
"ruleType": "MatchRule",
"state": "Enabled"
}
]`

However, if you want to use a structure like this to update the rule, the structure is different. This suggests the CLI implementation has a model object that expects different values, see here for an example that looks correct but which still fails on the "negation condition" aka "negation conditon". It actually expects a value of "negate"

`"customRules": [
{
"action": "Allow",
"matchConditions": [
{
"values": [
"/_framework/icudt_EFIGS.dat"
],
"variables": [
{
"variableName": "RequestUri"
}
],
"negationCondition": false,
"operator": "Contains",
"transforms": []
}
],
"name": "test-custom-rule",
"priority": 10,
"ruleType": "MatchRule",
"state": "Enabled"
}
]`

the difference lies with "variables" replacing "matchVariables" and "values" replacing "matchValues"

### Related command

az network application-gateway waf-policy show or az network application-gateway waf-policy update.

### Errors

When I try to use "update" it says:
`Failed to parse '--custom-rules' argument: Model 'AAZObjectArg' has no field named 'negationConditon'`
and when I correct the misspelling it also says the property is wrong:
`Failed to parse '--custom-rules' argument: Model 'AAZObjectArg' has no field named 'negationCondition'`

### Issue script & Debug output

Is this required?

### Expected behavior

The model object expected by the Azure CLI should behave in a less opaque fashion when translating to REST under the hood and hopefully the misspelling of the word Condition can be sent to the REST team to correct.

### Environment Summary

azure-cli 2.74.0 *

core 2.74.0 *
telemetry 1.1.0

Extensions:
ml 2.37.1
ssh 2.0.6

Dependencies:
msal 1.32.3
azure-mgmt-resource 23.3.0

### Additional context

_No response_