For undefined variables, explicitly raise a useful error on pickling

[beckjake]

resolves #2110

Description

Add a more coherent warning on pickling that indicates what the undefined value's name is and (importantly) what file it's in.

I wasn't able to fully remove the defining-Undefined-in-a-closure stuff because without it, we can't give a message indicating where we found the Undefined.

This is the new behavior:

$ cat models/y.sql
select * from {{ ref(x) }}
$ dbt compile
Running with dbt=0.17.0-a1
Encountered an error:
Compilation Error in model y (models/y.sql)
  x is undefined

I would have very much liked to remove the special undefined override, but because of how jinja handles undefined values, it's actually very difficult! You can't make it just raise on undefined, because constants like 1 show up as undefined (I don't understand why or how, but I didn't spend a lot of time on that because what are you going to do, change jinja?). Jinja really only has the capability of erroring out on explicit uses of undefined:

• missing.x -> can be an error (__getattr__(self) -> error)
• missing['x'] -> can be an error (__getitem__(self) -> error)
• missing * x -> can be an error (__mul__(self) -> error)

Cases like foo(missing)where foo doesn't call any of the forbidden magic methods apparently can't be an error without also breaking the use of bare integers.

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.

[drewbanin]

This LGTM! Nice one @beckjake