Fix!: serialize blueprint variables separately to leverage AST

[georgesittas]

Fixes #4017

Given a model like this:

MODEL (
  name m.@{foo},
  blueprints (
    (foo := "s p a c e s"),
    (foo := 'c'),
  ),
);

SELECT
  @foo AS col

The blueprint variables that contain quotes are incorrectly rendered today:

from sqlmesh import Context
ctx = Context()
for fqn, model in ctx.models.items():
    print(f"Fully-qualified name: {fqn}, name: {model.name}, query: {model.render_query().sql()}")

# Fully-qualified name: "db"."m"."""s p a c e s""", name: m."""s p a c e s""", query: SELECT '"s p a c e s"' AS "col"
# Fully-qualified name: "db"."m"."'c'", name: m."'c'", query: SELECT '''c''' AS "col"

This PR addresses this bug with the help of this commit, by changing the representation of the blueprint values: their values are now the parsed ASTs, and not the corresponding SQL strings. This behavior is more intuitive, because for example quoted identifiers will be correctly interpolated in contexts such as model names, without dropping the quotes.

Since SQLGlot expressions aren't serialized today, making this fix wasn't as simple as pushing the blueprint variables to the SQLMESH_VARS dict, since that only contains Python literals that can be eval'd on the fly without additional context, when hydrating the Python environment.

Additionally, we need to serialize blueprint values because if, e.g., a model query references them, then the raw SQL with the variable reference is serialized and we need to have the variable's payload at deserialization time to ensure the query can be properly rendered.

This led to a new dictionary in the python env. that will contain only the blueprint variables, so that we can unambiguously serialize them as strings that are produced by sql(dialect=...) and then deserialize them in the macro evaluator by parsing with the same dialect.

[izeigerman]

nice 👍