Add more context to unit tests and best practices

### Contributions

- [X] I have read the contribution docs, and understand what's expected of me.

### Link to the page on docs.getdbt.com requiring updates

[Per slack convo](https://dbt-labs.slack.com/archives/C06U7AG1X8E/p1713479803859709?thread_ts=1713478618.329389&cid=C06U7AG1X8E), the following unit test best practices/recommendations from @graciegoheen would be beneficial to add to the docs so users understand what works best for them:

### Inline vs. fixtures
- inline is better when you have a small number of edge cases, and you want to be able to see that data in your yml file that defines your unit test
- i think it’s easier to troubleshoot a unit test when everything is in the same file
- fixtures are better when you have lots of edge cases, so if you put it all in one yml file the file would be GIANT
- i also think fixures are better for the sql format
- but then you have to jump around between the fixture file and the yml file

### `dict` vs. `csv` vs.` sql`
- dict is the default, it’s always inline so contains your data in the yml file for easy viewing
- csv is what a lot of folks are used to if they’ve been using a unit testing package (via seeds) - so this is recommended for folks that are migrating from unit testing package, or who have less technical folks that prefer looking at csv
- sql is for expanding the type of data you can unit test
- can unit test more data types (think structs, geography, etc.)
- total control over the sql
- can unit test models that depend on ephemeral models
- BUT when using this format you must define mock data for all columns

### What part(s) of the page would you like to see updated?

https://docs.getdbt.com/docs/build/unit-tests

### Additional information

_No response_