Allow definition of additional attributes in generator configuration

**Context**
I am facing a scenario in which I have a terraform schema which in majority conforms with the schema defined in the API Spec, but terraform defines additional attributes which are populated using an unrelated endpoint.

**Enhancement request**

For these cases, it would be useful to give users flexibility in the generator configuration to define any additional attributes that are needed to define the complete schema of the resource.

As a proposal, the `attributes` object could define a new field for defining new properties and require the user to provide the attribute definition using the provider code specification. Example:
```
schema:
attributes:
overrides:
labels:
description: other description
additional: [
{
"name": "id",
"string": {
"computed_optional_required": "computed",
"plan_modifiers": [
{
"custom": {
"imports": [
{
"path": "github.com/hashicorp/terraform-plugin-framework/resource/schema/stringplanmodifier"
}
],
"schema_definition": "stringplanmodifier.UseStateForUnknown()"
}
}
]
}
}
]
```

### Edit from @austinvalle
Bringing over some information from #84 that would also fit in this request:

> - Define **plan modifiers** for specific attributes. This is useful for common plan modifiers such as `RequiresReplace` and `UseStateForUnkown`.
> - Define **validators** for specific attributes. Apart from validators that are generated from API Spec properties, there are other validations such as `ConflictsWith` which cannot be represented easily in an OpenAPI Spec.
> - Allow overriding the resulting **name** of an attribute, giving flexibility in the case that terraform schema has a different name from the definition in the API.
> - Marking an attribute as **sensitive**. This is information that likely cannot be inferred from the API Spec but highly relevant for terraform schema.
> - Allow override of the `computed_optional_required` property for an attribute. While the tool has a certain logic to define this value for attributes, it would be helpful to give flexibility to the user to cover specific edge cases.

Also some from #85:
> Currently schemas of "type" : "array" with nested objects are being defined as attribute lists. While this is correct, terraform has a broader set of possibilities:
> - can be of type `list_nested` or `set_nested`.
> - defined as an `attribute` or as a `block`.