[CT-2198] Unify constraints and constraints_check configs

[MichelleArk]

Refinement discussion: #6750

In #6271, constraints: List[str] and constraints_check: str are optional column configs that configure column-level constraints and row-level checks respectively.

Current data structure

columns:
  - name: price
    data_type: numeric
    constraints:
      - not null
    constraints_check: price > 0

Proposed data structure

Constraint is a new object type. Pseudo code:

class ConstraintOption(StrEnum):
    check = "check"
    not_null = "not_null"
    unique = "unique"
    primary_key = "primary_key"
    foreign_key = "foreign_key"
    custom = "custom"  # I have no idea -- but let's leave it open for the wacky & wild data platforms out there

ColumnLevelConstraint:
    type: ConstraintOption
    name: Optional[str]
    warn_unenforced: bool = True  # raise a warning if this constraint is not enforced by this data platform (but will still be included in templated DDL)
    warn_unsupported: bool = True  # raise a warning if this constraint is not supported by this data platform (and will be excluded from templated DDL)
    expression: Optional[str] # free for all. required if constraint is 'check' or 'foreign_key' -- can we validate via post-init ?
    # additional properties allowed: yes! there are going to be lots of constraint-specific and platform-specific shenanigans

# the same, with an added 'columns' attribute (which isn't needed when the constraint is defined for one column)
ModelLevelConstraint(ColumnLevelConstraint):
    columns: List[str]

models:
  constraints: # type: Optional[List[ModelLevelConstraint]]
  columns:
    - name: # type: str
      data_type: # type: Optional[str]
      constraints: # type: Optional[List[ColumnLevelConstraint]]

Notes:

• constraints is an optional attribute at both the model level and the column level
• If constraints is set a the model level, it should be a model-level attribute, not a "config." This means it isn't settable in {{ config() }} or in dbt_project.yml, and that's okay.
• warn_unenforced & warn_unsupported could alternatively be Optional[bool], and flipped/renamed to ignore_warning_unenforced & ignore_warning_unsupported, so that the data is only included when it's a non-default value
• This will require changes in adapter macros to obtain constraints information from the new data structure to build constraint ddl.