Add section headers to separate the different sections (#5776)

[Preview](https://docs-getdbt-com-git-dbeatty10-patch-1-dbt-labs.vercel.app/reference/resource-configs/contract)

## What are you changing in this pull request and why?

The
[`contracts`](https://docs.getdbt.com/reference/resource-configs/contract#example)
page includes some important information as it relates to size,
precision, and scale when enforcing contracts, but it's hard to pick out
visually.

I want to be send hyperlinks to folks that points to just the right
section. For example, in this issue:
dbt-labs/dbt-core#10430.

## Checklist
- [x] Review the [Content style
guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md)
so my content adheres to these guidelines.

website/docs/reference/resource-configs/contract.md

@@ -14,6 +14,8 @@ When the `contract` configuration is enforced, dbt will ensure that your model's
 
 This is to ensure that the people querying your model downstream—both inside and outside dbt—have a predictable and consistent set of columns to use in their analyses. Even a subtle change in data type, such as from `boolean` (`true`/`false`) to `integer` (`0`/`1`), could cause queries to fail in surprising ways.
 
+## Data type aliasing
+
 <VersionBlock lastVersion="1.6">
 
 The `data_type` defined in your YAML file must match a data type your data platform recognizes. dbt does not do any type aliasing itself. If your data platform recognizes both `int` and `integer` as corresponding to the same type, then they will return a match.
@@ -42,11 +44,13 @@ models:
 </File>
 </VersionBlock>
 
+## Size, precision, and scale
+
 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](/best-practices/writing-custom-generic-tests).
 
 Note that you need to specify a varchar size or numeric scale, otherwise dbt relies on default values. For example, if a `numeric` type defaults to a precision of 38 and a scale of 0, then the numeric column stores 0 digits to the right of the decimal (it only stores whole numbers), which might cause it to fail contract enforcement. To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`. dbt Core 1.7 and higher provides a warning if you don't specify precision and scale when providing a numeric data type.
 
-## Example
+### Example
 
 <File name='models/dim_customers.yml'>