Take configuration instance changes into account in refresh report

### Terraform Version

```
Terraform v1.0.4
on linux_amd64
+ provider registry.terraform.io/hashicorp/azurerm v2.71.0
```

### Terraform Configuration Files

```terraform
provider "azurerm" {
features {}
}

resource "azurerm_resource_group" "main" {
# count = 1
name = "can-i-count-rg"
location = "westeurope"
}
```

### Debug Output

N/A

### Crash Output

N/A

### Expected Behavior

Terraform should not report changes outside of terraform when outside configuration matches desired configuration.

Another less surprising option would be that when adding/removing count it looks like a completely new resource and would need explicit migration of the statefile (through `state rm ... && import`), althought that might count as a breaking change to today's behaviour.

### Actual Behavior

Terraform claims that a resource has been removed outside of terraform, while not offering to create it.

```
Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

# azurerm_resource_group.main has been deleted
- resource "azurerm_resource_group" "main" {
- id = "/subscriptions//resourceGroups/can-i-count-rg" -> null
- location = "westeurope" -> null
- name = "can-i-count-rg" -> null
- tags = {} -> null
}

Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using
ignore_changes, the following plan may include actions to undo or respond to these changes.

───────────────────────────────────────────────────────────────────────────────────────────────────────────

No changes. Your infrastructure matches the configuration.

Your configuration already matches the changes detected above. If you'd like to update the Terraform state
to match, create and apply a refresh-only plan:
terraform apply -refresh-only
```

### Steps to Reproduce

Tiny bit more detail here https://github.com/sharebear/terraform-bug-reproductions/tree/master/count-problems

```
$ terraform init
$ terraform apply -auto-approve
$ terraform plan

# observe no changes
```

Uncomment line 6 in main.tf

```
$ terraform plan
```

### Additional Context

Through the lifecycle of a module, I have found it useful to use variables as feature flags to turn on or off resources as I migrate strategies for doing things. In this way I can follow something close to trunk based development where I can introduce changes to dev/test environments without affecting prod until I know they work as intended, without the overhead of versioning. This has worked fine with terraform 0.14.x but I tried upgrading to 1.0.4 today and stumbled into this interesting behaviour when adding a count to a resource that previously didn't have a count.

From the presentation of the output it looks like terraform is going to remove a live resource from the state file, which was mildly terrifying as then I would need to re-import everything (or restore state from backup). While experimenting with the minimal case I see now that the message, while confusing, is harmless and terraform still behaves as it did in 0.14.x.

### References

I see there are some issues with the change detection and for_each that might be related, but I'm not certain enough to link them in here.

Start with the linked count-problems reproduction and the main.tf configuration, then run the listed terraform init, apply, and plan commands before and after uncommenting line 6. Trace how the refresh report handles the configuration instance change. Done means the report no longer claims an external deletion without offering the corresponding configuration action, with regression coverage for this sequence.

Written by the indexing model from the issue text.