Enact deprecations

Describe the feature

• As of dbt v0.18.0, we collect anonymous usage stats for deprecation warnings.
• We were already planning to end support for config-version: 1 of dbt_project.yml in dbt v0.19.0 (per implementation of #2735)
• We should officially deprecate:
  • dbt-project-yaml-1: this is far & away the most common deprecation warning, and we still see it popping up in ~40% of projects running v0.18.0. Users may have upgraded their own projects but still need to upgrade installed packages. In any case, this is definitely the most controversial of our proposed deprecations.
  • column-quoting-unset: 11% of projects
  • models-key-mismatch: 2% of projects
  • materialization-return: <1% of projects
  • not-a-dictionary: 0% of projects
• We should not deprecate:
  • adapter-macro: this is the second-most-common deprecation warning, and we only introduced it in v0.18 with the switch to adapter.dispatch. We should give users at least one more minor version to upgrade.

Describe alternatives you’ve considered

• Leaving these as warnings until v1.0.0, or forever

Who will this benefit?

• Us as dbt maintainers in the short term, as we can reduce the surface area of code that patched older syntaxes
• Users, in the long run, as we continue to crystallize the UX of dbt project development

[emmyoop]

All deprecations listed above have been merged into develop. Closing.

[emmyoop]

Opened #415 in dbt-utils because of newly introduced use of packages. Will need to be resolved before enacting deprecation for dispatch-packages.