Odd behavior when changing kind/OS of app service plan

**Bicep version**
`Bicep CLI version 0.4.1124 (66c84c8ee5)`

**Describe the bug**
Here's my resource definition:
```
resource plan 'Microsoft.Web/serverfarms@2021-02-01' = {
name: planName
location: resourceGroup().location
tags: resourceGroup().tags
kind: planOS
sku: {
name: planSKU
}
properties: {
reserved: toLower(planOS) == 'linux' ? true : null
}
}
```
Running this with `planOS=Windows` and `planSKU=S1` succeeds just fine. If I change this to `planOS=Linux` and run again, the operation succeeds, but there is conflicting information about the plan's settings in the portal:


If I run this again with `planOS=Linux` and also adding `planSKU=S2`, this is the output from `--what-if`:

```
Note: The result may contain false positive predictions (noise).
You can help us improve the accuracy of the result by opening an issue here: https://aka.ms/WhatIfIssues

Resource and property changes are indicated with these symbols:
~ Modify
* Ignore

The deployment will update the following scope:

Scope: /subscriptions/REDACTED/resourceGroups/REDACTED

~ Microsoft.Web/serverfarms/REDACTED [2021-02-01]
~ sku.name: "S1" => "S2"

* Microsoft.Storage/storageAccounts/REDACTED
* microsoft.alertsmanagement/smartDetectorAlertRules/Failure Anomalies - REDACTED
* microsoft.alertsmanagement/smartDetectorAlertRules/Failure Anomalies - REDACTED
```
And this is the output when deploying for real, without `--what-if`:

```
{"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n \"Code\": \"BadRequest\",\r\n \"Message\": \"You cannot change the OS hosting your app at this time. Please recreate your app with the desired OS.\",\r\n \"Target\": null,\r\n \"Details\": [\r\n {\r\n \"Message\": \"You cannot change the OS hosting your app at this time. Please recreate your app with the desired OS.\"\r\n },\r\n {\r\n \"Code\": \"BadRequest\"\r\n },\r\n {\r\n \"ErrorEntity\": {\r\n \"ExtendedCode\": \"59315\",\r\n \"MessageTemplate\": \"You cannot change the OS hosting your app at this time. Please recreate your app with the desired OS.\",\r\n \"Parameters\": [],\r\n \"Code\": \"BadRequest\",\r\n \"Message\": \"You cannot change the OS hosting your app at this time. Please recreate your app with the desired OS.\"\r\n }\r\n }\r\n ],\r\n \"Innererror\": null\r\n}"}]}}
```
For your convenience, the error message here is _You cannot change the OS hosting your app at this time. Please recreate your app with the desired OS._

**To Reproduce**
Repro steps are described above.

**Additional context**
I was initially trying to change the kind/OS of an already-deployed plan. I have experience with Terraform, and Terraform will offer to destroy and re-create the plan in that scenario, so I assumed it would work with Bicep too. After thinking about it, I understand now that since Bicep doesn't have state files, it's probably pretty difficult to draw a hard link between a resource in the Bicep file and the actual resource in Azure (imagine if I changed the name, for example). So it'd be okay with me if you don't plan to support that functionality by design.

However the other behavior here seems odd. I don't understand why the first run with `planOS=Linux` left the plan in an odd state in the portal (one place says it's a Linux plan, the other says Windows), or why that run didn't give the error encountered when changing the SKU in the next run. Also the `--what-if` output doesn't mention that the OS change can't and won't happen when it probably should.

Start with the resource definition and reproduction steps in the issue, using the Bicep CLI version shown. Run the Windows-to-Linux update, then the Linux SKU update with --what-if and without it, and compare the deployment operations with the portal state. Done means the immutable OS change is accurately reported or rejected without leaving contradictory plan information.

Written by the indexing model from the issue text.