Consider Surfacing Framework Type System Data for Config/Plan/State

### Module version

```
v1.0.0
```

### Use-cases

Provider developers should not need to drop down to the `github.com/hashicorp/terraform-plugin-go/tftypes` type system for advanced use cases that require working with schema-based data directly. In particular, `tfsdk.Config`, `tfsdk.Plan`, and `tfsdk.State` type `Raw` fields are currently `tftypes.Value`. Instead, providers should be able to work with the framework's type system for consistency, such as `types.Object`. If the `tftypes` data handling was still necessary by providers for whatever reason, they could still use the type implementations of `ToTerraformValue()` and `FromTerraformValue()` to roundtrip back and forth.

This effort would also help clean up _a lot_ of framework internal logic that goes back and forth between the two type systems.

### Proposal

_This will require a large amount of design effort to complete successfully and this proposal is not currently exhaustive. It is being written in the context of closing out the generic #172._

Likely, some `tftypes` functionality such as walking and transforming values may be desirable in the framework type system or at least available internally within the framework.

Then, one of the following approaches could be taken to expose the data using the framework's type system:

#### Existing Type Approach

Add a new exported `types.Object` retrieval method to the existing `tfsdk` types. Deprecate the `Raw` field.

This introduces the least changes for providers and the framework, but does not fix the framework's technical debt imposed by the data storage being an exported `tftypes.Value`. Without a setter method, this also means that providers must use `(types.Object).ToTerraformValue()` to save the data back, which could be awkward.

#### New Type Approach

New schema-based data types could be introduced in the `datasource`, `provider`, and `resource` packages based off the framework type system which deprecate the existing `tfsdk` types. This enables fully executing the vision of each concept being self-contained within its own package in the framework. Various requests/responses would need the `tfsdk` based fields to be deprecated in preference of new fields using the new types.

This approach would also allow a more tailored design that no longer exposes any implementation details as errantly mutable fields, but more design would be needed on that front.

### References

- #172
- #366