Port adapter_macro implementation into Python

[drewbanin]

Describe the feature

Right now, the adapter_macro implementation is written in jinja. It doesn't really do any string templating, so it's a better candidate for Python code. Rewriting this macro in Python would let us add some more comprehensive unit tests, and be more flexible with the implementation.

In addition to moving this macro to Python, I think we should rename it to dispatch, and it should live on the adapter object. Example usage:

{% macro debug(args...) %}
  {% set macro = adapter.dispatch(macro_name='debug', packages=[...]) %}
  {% do return macro(args...) %}
{% endmacro %}

Here, dispatch takes two arguments:

1. The macro name to dispatch
2. A list of of packages/namespaces to search for the macro in

The macro resolution order should largely be the same as the current implementation with one notable difference. Instead of namespacing a macro in the macro_name argument (eg. dbt_utils.debug), we'd be able to supply a list of namespaces to search in. Package maintainers could use this functionality to allow 3rd-party packages to extend the adapter-specific implementations provided in the base package.

A quick example:

-- dbt-utils: macros/debug.sql

{% macro get_macro_namespaces() %}
  {% do return(var('namespaces') + ['dbt_utils'] if var('namespaces') is not none else ['dbt_utils'] %}
{% endmacro %}

{% macro debug() %}
  {% set macro = adapter.dispatch(macro_name='debug', packages=get_macro_namespaces()) %}
  {% do return(macro()) %}
{% endmacro %}

{% macro default__debug() %}
  {% do log("default impl", info=true) %}
{% endmacro %}

-- spark-utils: macros/debug.sql

{% macro spark__debug() %}
  {% do log("spark impl", info=true) %}
{% endmacro %}

1. There's a ton of opportunity for syntactic sugar here, so take this as a thing we could support, not a final spec!
2. We can probably do a better job than what's described in get_macro_namespaces above