Move --full-refresh into a model config

[drewbanin]

Feature

Feature description

Presently, --full-refresh and --non-destructive can only be set on the CLI and apply to all models. Instead, these flags should be pushed down as model configs. The --non-destructive and --full-refresh flags can still exist, but they should set individual model configurations under the hood.

Since these configs will be specified with model-level granularity, complex behavior can be coded using variables, macros, etc.

Who will this benefit?

Users with sophisticated dbt deployments who need to trigger complex dbt invocations

Via @elexisvenator in Slack:

I want to run dbt as frequently as possible, which means ideally I only want to run models with data that has changed, or where a model has changed.
I already have the means to know which source tables have changed, and which model files have been modified since last run.

See also: #320

[drewbanin]

Presently, flags are set at a global level in dbt. In main.py, dbt plucks configuration values out of the parsed CLI arguments and sticks them into the global fields defined in flags.py.

In the jinja layer, materializations use these flags to determine exactly what SQL should be run. There's an example of that over here.

A better approach is to add new configuration options (like non_destructive or full_refresh) for dbt resources, then use the global flags to set these options on the resources during parsing. Finally, the materialization code can be updated to reference an attribute of a model, like model.full_refresh, rather than pulling this value from the flags directly.

As a result of this change, the behavior of the --full-refresh flag will not change, but users can optionally supply a full_refresh configuration option to configure specific models based on the value of a variable, for instance.

This might be out of scope for this issue, but I think we should deprecate (and eventually remove) the --non-destructive flag/concept entirely from dbt. That flag existed as a workaround for Redshift's bound views, which the incidence of late-bound views wholly obviates!