Fix: parse runtime-rendered fields, extract python env deps from merge_filter

[georgesittas]

While iterating on a separate task locally, I observed that there are a couple of gaps in our "runtime-rendered" property handling logic:

• We don't parse Python strings corresponding to said properties. This means we don't analyze them to extract referenced variables, which can lead to issues at runtime (e.g., cadence runs), due to these variables not being present in python_env, and hence failing to render.
• We don't analyze merge_filter for variables. This is true for both Python and SQL models. Again, this means that if a variable is referenced in merge_filter, it may not be present in the python_env of the model and hence we may fail to render it at runtime.

This PR addresses both of the issues above and expands our testing coverage to ensure we properly detect the referenced variables in runtime-rendered properties.

I'm not sure yet if this needs a migration script, because if someone references variables in said properties today, then cadence runs would've failed for them anyway if the variables weren't present in the python_env. I'd like some eyes on this to double-check my reasoning.

[georgesittas]

These were added some time ago to avoid parsing & rendering things like cron="@daily", or description="... @bar ...", where @bar is just a literal substring of the description, not a variable reference.

I'm not sure if this is the right approach, because we may have more fields with "string literals", where we don't care about rendering variables. I decided to simply preserve what we do today to avoid increasing the scope, but this is probably worth discussing & addressing in a followup PR.

[themisvaltinos]

looks good to me, the only concern is regarding the need of a migration script, but I think your theory is correct, since if someone had macro vars in the merge_filter before they would have failed to be rendered