Rework dispatch, with backwards compatibility for current use

[jtcohen6]

resolves #3362
resolves #3383

This just adds a reproduction case for now. I've confirmed that, when I run pytest locally, it raises the same error we're seeing in the wild:

E       dbt.exceptions.CompilationException: Compilation Error in test pkg_and_dispatch_model_c_ (test-context-models/schema.yml)
E         'dict object' has no attribute 'current_timestamp'
E
E         > in macro test_pkg_and_dispatch (macros/custom_test.sql)
E         > called by macro default__test_pkg_and_dispatch (macros/custom_test.sql)
E         > called by test pkg_and_dispatch_model_c_ (test-context-models/schema.yml)

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.

[jtcohen6]

I confirmed that this offers backwards compatibility for the dbt-utils package. Hooray! I moved a little of the logic around, to account for when packages is a positional arg and also a Call, and I touched up the error message. (Looks like I messed up the flake8 linting, sorry about that.)

I'm so happy to be adding this logic and ensure projects have a smooth upgrade path to v0.19.2 + v0.20.0; I also want to get "the right way" to do this in place, and immediately recommend it to everyone who's upgrading. I laid out my sketch of a longer-term sustainable solution over in #3383.

[jtcohen6]

These changes are looking really good! I confirmed they worked with dbt-utils, both with:

• The setup as it exists today
• The changes we'll want to make to support the new dispatch project config

I left a few comments, nothing major.

Next steps from here:

• Merge this PR into develop (or a new one, it doesn't have to be the one I stubbed out last week! haha)
• Cherry-pick this PR onto 0.19.latest
• Create a new PR, for inclusion in develop (v0.20) only, that raises a deprecation warning if the user either provides the packages kwarg or passes a list to the second positional arg

[jtcohen6]

Could we adjust this test, or add another one, to confirm that when a user sets this to

"search_order": ['another_package', 'test_utils']

dbt will indeed prefer the version of the macro defined in another_package? Ultimately, that's the dispatch functionality that we want to be safeguarding here.