Creating non linux app service plan should fail when the kind field sets to non linux and the Reserved field sets to true

After tested, I found service api would always create `linux` app service plan even if the `kind` field sets to `"Windows/App/elastic/FunctionApp/xenon"` and the `Reserved` field sets to `true`. I assume it doesn't make sense. It should throw error message if it doesn't allow this kind of scenario.

Below is the example of http request.
1. Try to create app service plan whose the kind field is windows and the reserved field is true:
```
PUT https://management.azure.com/subscriptions/xx-xx-xx-xx/resourceGroups/test-appservice-rg02/providers/Microsoft.Web/serverfarms/acctestASP-windows2

{
"kind": "Windows",
"location": "westeurope",
"properties": {
"reserved": true,
"isXenon": false
},
"sku": {
"name": "S1",
"tier": "Standard",
"size": "S1",
"capacity": 0
},
"tags": {}
}
```

2. Get app service plan but the kind field is still linux:
```
GET https://management.azure.com/subscriptions/xx-xx-xx-xx/resourceGroups/test-appservice-rg02/providers/Microsoft.Web/serverfarms/acctestASP-windows2?api-version=2019-08-01

{
"id": "/subscriptions/xx-xx-xx-xx/resourceGroups/test-appservice-rg02/providers/Microsoft.Web/serverfarms/acctestASP-windows2",
"name": "acctestASP-windows2",
"type": "Microsoft.Web/serverfarms",
"kind": "linux",
"location": "West Europe",
"tags": {},
"properties": {
...
"kind": "linux",
...
},
}
```

Start by locating the API definition for the Microsoft.Web/serverfarms endpoint and review how the request's kind and properties.reserved fields are modeled. Reproduce the PUT example, then define the expected rejection for non-Linux kinds with reserved set to true and verify that valid app service plan requests still work.

Written by the indexing model from the issue text.