Tests are configurable from dbt_project.yml

[jtcohen6]

Describe the feature

This issue brings tests up to parity with other resource types in terms of being able to configure them from dbt_project.yml. In particular, this is essential for being able to control the behavior of tests installed from packages.

dbt_project.yml

# top-level: both bespoke + generic tests
tests:
  +enabled: true
  +severity: error
  +tags: ["tag_one", "tag_two"]
  
# for specific instances of generic tests defined on models
models:
  my_project:
    my_subfolder:
      +tests:
        enabled: true
        severity: warn

# for specific instances of generic tests defined on seeds
seeds:
  installed_package:
    +tests:
      enabled: false

# for specific instances of generic tests defined on snapshots
snapshots:
  +tests:
    tags: ["tag_three"]

# for specific instances of generic tests defined on sources
sources:
  +tests:
    severity: warn

What does it mean to configure...

1. A bespoke test (e.g. test/my_test.sql)? Same it does today when I put {{ config(severity = 'warn') }} at the top of test/my_test.sql.
2. A generic test (e.g. unique)? I should be able to add either {{ config(severity = 'warn') }} to my test block definition, or severity=warn as a default argument in the test signature. All specific instances of the unique test will now be warn-severity by default, unless the specific test overrides as below. (Note: There was a regression for this in v0.19.1, see v0.19.1 test severity='warn' ignored #3240).
3. A specific instance of a generic test (e.g. unique_model_a_id)? Same as it does today when I add an "argument" to the test definition:

        tests:
          - unique:
               severity: warn

In this way, for generic tests, configs are like a special type of test block (macro) argument. You could think about this issue as being a way to "pass" arguments to a bunch of instantiated generic tests all at once, right from dbt_project.yml. That said, there are a few differences between configs and arguments for generic tests:

• Configs apply to all tests, bespoke and generic. Arguments are specific to one generic test block (e.g. the values for accepted_values)
• Only config values can be passed from dbt_project.yml
• How the unique_id is constructed for a specific test node (see Better unique_id construction for specific instances of generic tests #3254)

Hierarchy

1. Most specific always wins: The config() block in a data test, or the value passed to a specific instance of a generic test where it's defined in (e.g.) a models/*.yml file
2. The default values set within the generic test block (either by config() block or by default arguments in the signature)
3. Config in dbt_project.yml, applying to all tests
4. The configs of installed packages (1-3)

Edited: I previously had 2 last, but this is going to be difficult given the way this is implemented today. I don't mind the idea that the generic test's default values are still more specific than dbt_project.yml config. I'm also not sure how to think about #3256 relative to the ordering above.

Additional context

Today, the only supported configs for tests are enabled, severity, and tags (docs). Generic tests support severity + tags, and they should enabled (#3252). We hope to add net-new configs very soon as well (e.g. where, limit).