Feat(dbt): Add config object to provide methods aligned with dbt

[themisvaltinos]

This adds support for the config variable and its methods. This exists to handle end-user configuration for custom materialisations and this a first part in supporting that, but also in general to align with dbt's config.

{% materialization incremental, default -%}
-- Example w/ no default. unique_key will be None if the user does not provide this configuration
{%- set unique_key = config.get('unique_key') -%}

-- Example w/ alternate value. Use alternative of 'id' if 'unique_key' config is provided, but it is None
{%- set unique_key = config.get('unique_key') or 'id' -%}

-- Example w/ default value. Default to 'id' if the 'unique_key' config does not exist
{%- set unique_key = config.get('unique_key', default='id') -%}

-- Example of a custom config nested under `meta` as required in v1.10 and higher.
{% set my_custom_config = config.get('meta').custom_config_key %}
...

[georgesittas]

Does this PR affect the snapshot payload, i.e., can it result in post-migration diffs?

[themisvaltinos]

Does this PR affect the snapshot payload, i.e., can it result in post-migration diffs?

it shouldn't no as the payload would stay the same, the config dictionary was part of the payload and nothing changes regarding it's structure only the way it is accessed and modified. Now if there were jinja macros that were using the config.get with default methods etc. they would simply fail now as they weren't supported by sqlmesh and if there were macros that were using the dot notation they now won't fail but simply return nothing (which would match what happens in dbt as well for the config variable)

[georgesittas]

LGTM.