Support Behavioral Fields

### Module version

```
v0.1.0
```

### Use-cases

There are several situations in which a field should be considered behavioral. It's not tracking state under management, it's controlling how a resource works. For example, `prevent_destroy`, `prevent_overwrite`, etc. Provider developers want to be able to offer users flags to control how resources behave.

### Attempted Solutions

Adding these fields as part of the schema works, but comes with some negative side-effects in SDKv2. For example, a field must be applied before it shows up in state, which limits some of the functionality in some places. Users see unnecessary, spurious diffs.

### Proposal

The proposal is to have a schema-defined, provider-controlled set of behavioral fields on each resource. The schema and values could be stored in the `private` area of the request/response, much like timeouts were. This would allow providers to define fields that control behaviors, don't diff, and don't have weird interactions with whether they've been applied yet or not.

### References