[Feature] Add precision and scale option for data type constraints

### Is this your first time submitting a feature request?

- [X] I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
- [X] I have searched the existing issues, and I could not find an existing issue for this feature
- [X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

### Describe the feature

The dbt docs on contracts state
> When dbt compares data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between varchar(256) and varchar(257), because it doesn't really affect the experience of downstream queriers. You can accomplish a more-precise assertion by [writing or using a custom test](https://docs.getdbt.com/best-practices/writing-custom-generic-tests)

However the advantage of contracts is that they fail a model _before_ data is written to the target table whereas tests will only throw up a failure after the data has already been corrupted. It would be better to expose a boolean option that lets the user choose whether or not they want to opt in to enforcing precision and scale for numeric and string data types.

I can think of several situations where knowing that new model logic is not altering the precision of a text or numeric field would be extremely valuable.

### Describe alternatives you've considered

This feature wouldn't be necessary if dbt tests supported a write audit publish pattern out of the box. For example dbt could build a temporary table - run data tests on that table and then only swap it with the target if the tests are in a passing state. This behaviour would bring this functionality entirely under the banner of dbt testing and not model contracts.

### Who will this benefit?

Everyone

### Are you interested in contributing this feature?

maybe - if i'm pointed in the right direction in the code base

### Anything else?

_No response_