Feature: test config parity

[jtcohen6]

resolves #3252
resolves #3253

This PR makes it possible to:

• Disable schema tests where they're defined
• Configure tests from dbt_project.yml

models/*.yml:

      tests:
        - not_null:
            enabled: true
        - accepted_values:
            values: [1,2,3]
            enabled: false

dbt_project.yml:

tests:
  my_project:
    +severity: warn
  installed_package:
    +enabled: false

Differences from proposal in #3253

• Rather than configuring schema tests underneath each of models/sources/etc, all tests are configured under tests:. I think that's okay.
• (After we solve v0.19.1 regression): Generic tests' default configs/arguments will override configurations set in dbt_project.yml. That's not the order I had originally envisioned, but again I think that's okay; it's up for debate which one is actually more generic / specific.

Next issues

• Net-new configs (Net-new test configs #3258)
• Test FQNs could be a lot better, to make configuration easier (Improve test FQNs #3259)

Checklist

• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

[kwigley]

ah!

[gshank]

I'm wondering about the use of ResourceType.Test.... It applies in some cases to everything in a schema file, not just tests. I introduced a ParseFileType in the load_all_files branch. Perhaps we should straighten out the ambiguous use of 'tests' for all schema files things versus just tests.

[jtcohen6]

@gshank Could you say more about that? I just did a quick search for all the places NodeType.Test crops up, and all of them seem to be specific to data tests + schema tests. Granted, there are some wonky things we do to construct schema tests while reading schema (non-project .yml) files...

[jtcohen6]

@kwigley This is actually the line that fixed the Undefined Jinja error, because I was accidentally passing the config down on line 329 as:

{{ config(severity = warn) }}

Instead of severity = 'warn', i.e. string literal. And, well, warn is not a defined Jinja variable.

At the same time, we can't quote values that need to be non-string types (namely, enabled is boolean). This is a pretty janky way of writing that, I'm sure there's a more pythonic / f-string-smart way to do it.