Ability to Conditionally Mark Schema Attributes Sensitive

_Please Note: This issue is being submitted in the absence of an existing one I could find and meant more for gathering other use cases and/or showing an explicit decision on the subject. Especially in Terraform CLI 0.15 and later, most practitioners can and probably should use `sensitive = true` variable blocks or the `sensitive()` function to explicitly enable sensitive value handling where it is not present in providers. Conversely, the `nonsensitive()` function can be used to workaround provider-based sensitive values in downstream references as necessary. There is potential for this issue to be moot for code enhancements (except maybe comments around the helper/schema.Schema Sensitive field), but maybe left as tracking towards documentation and education efforts._

### SDK version

```
v2.5.0
```

### Use-cases

Currently, the Terraform Plugin SDK does not provide functionality to conditionally mark or unmark sensitive attributes. In numerous cases, provider developers have had to compromise by marking certain attributes with `Sensitive: true` in their schema while the value may not be always sensitive based on other resource configuration. When a provider attribute, especially in Terraform CLI 0.15 and later, is marked sensitive, but does not actually have a sensitive value, it has a lot of user experience consequences, including:

- Hiding potentially helpful plan difference output, especially:
- Maps, where keys are hidden
- Blocks, where all values for the attribute are hidden
- In Terraform CLI 0.15 and later: requires configuration changes to update `output` blocks to include `sensitive = true` or wrap sensitive values with the `nonsensitive()` function. This may not be intuitive since it previously worked fine for practitioners.

For a canonical AWS Provider example, see the `aws_ssm_parameter` resource, which accepts a `String` type or `SecureString` type for the parameter. It is currently set as `Sensitive: true`. I'll reference other issues/resources below where we have seen this request for conditional sensitivity in the AWS Provider as well.

### Attempted Solutions

In the AWS Provider example, debating on whether to create a separate "sensitive"/`SecureString` resource:

- If the new resource was the "sensitive" one, this requires a lot of practitioner burden though as they must know that a new resource exists and must migrate. It also would mean the developers would need to choose when to remove the sensitivity from the existing resource, which likely would not be welcomed by the community until a major version release in a long timeframe.
- If the new resource is the "non-sensitive" one, there still is a lot of practitioner burden to learn about and migrate to the new resource.

### Proposal

Enhance the SDK (presumably after Terraform CLI and Terraform Plugin Protocol changes) to support conditional sensitivity on attributes, similar to how `ForceNew` can be applied conditionally.

### References

- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudformation_stack (template_body with sometimes sensitive parameters)
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/elastic_beanstalk_environment (setting values, only which some key-values are sensitive)
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/opsworks_application (environment values based on `secure` flag)
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_object (content)
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ssm_parameter (value)
- https://github.com/hashicorp/terraform-provider-aws/issues/9090
- https://github.com/hashicorp/terraform-provider-aws/issues/9105
- https://github.com/hashicorp/terraform-provider-aws/issues/11595
- https://github.com/hashicorp/terraform-provider-aws/issues/15447
- https://github.com/hashicorp/terraform-provider-aws/issues/15771
- https://github.com/hashicorp/terraform/issues/28321

Start by reviewing the helper/schema.Schema Sensitive field and the referenced Terraform CLI and Plugin Protocol issues. The proposal depends on changes outside this SDK and is framed as a request for use cases and an explicit decision, so completion would require an agreed design before implementation scope can be defined.

Written by the indexing model from the issue text.