Add `Config` to the `resource.ReadRequest`

### Module version

```
v1.4.1
```

### Use-cases

Allow users to (optionally) specify a default value for a common argument in many resources and data sources.

I.e., the resources and data sources have optional and computed `foo` attribute. If not specified, the value from the provider attribute `foo` would be used. If even that is not specified, fail the run.

For example:

```terraform
provider "my" {
foo = "bar"
}

resource "my_example" "this" {
# `foo` taken from the provider config
}

resource "my_example" "that" {
# Explicitly set
foo = "zap"
}
```

### Attempted Solutions

I have thought and tried different solutions, but all have their issues. I might of course miss something here.

1. [Defaults](https://developer.hashicorp.com/terraform/plugin/framework/resources/default) are applied before the resource is configured, so it doesn't have access to the provider configuration.
2. [Attribute Plan Modifier](https://developer.hashicorp.com/terraform/plugin/framework/resources/plan-modification#attribute-plan-modification) doesn't have access to the resource and thus provider configuration.
3. [Resource Plan Modifier](https://developer.hashicorp.com/terraform/plugin/framework/resources/plan-modification#resource-plan-modification) has all the needed configuration, but if `foo` is configured in the provider and changes, updating the resource will lead to the `Provider produced inconsistent result after apply` error on other computed fields. In a single resource it would be fine to set all to unknown in the `ModifyPlan()`, but no idea how to iterate them in a generic way if the same function is used in many resources.
4. Setting the default in `Create()` works. But in `Read()` there is no access to the `Config` and the `State` has the old value, so if the value comes from the provider, any changes are not detected. Another downside is that in diffs the value is always `(known after apply)`.
5. Using another attribute for the actual value sounds verbose, and not sure it would help in many of the previous cases.
6. With data sources `Read()` seems like the only option, but there it works fine.

### Proposal

Add `Config` to the `resource.ReadRequest` struct to be accessible in the resource's `Read()` function.

Of course if there are other ways to implement this, nice. 🙂
Some way for setting all the computed, `null` configured attributes back to unknown at least would be fine.