feat(jinja): add b64decode/b64encode builtin filters

[anxkhn]

Description

Core SQLMesh ships no builtin Jinja filters, so there is no in-tree way to decode a base64-encoded value inside a config YAML. As issue #5754 notes, this is awkward for secrets that are commonly stored base64-encoded in environment variables (for example a GCP/BigQuery service-account key), since they cannot be decoded where the connection config is rendered.

This adds two builtin filters, b64decode and b64encode (matching ansible's filter names referenced in the issue), and registers them on the shared Jinja environment() factory in sqlmesh/utils/jinja.py. Because ENVIRONMENT is built from that factory and config files are rendered through it, the filters work in config YAML:

env_vars:
  BIGQUERY_KEY: "{{ env_var('BIGQUERY_KEY_B64') | b64decode }}"

They are also available in models, since the model JinjaMacroRegistry builds its environment from the same factory. Both helpers are str/bytes tolerant and return str. This mirrors the existing dbt builtin-filter pattern (create_builtin_filters in sqlmesh/dbt/builtin.py).

Closes #5754

Test Plan

• Added test_builtin_base64_filters in tests/utils/test_jinja.py: renders b64decode/b64encode (and a round-trip) via a built environment, and asserts the filter is usable in config YAML through yaml.load.
• Confirmed the new test fails on main (No filter named 'b64decode') and passes on the branch.
• pytest tests/utils/test_jinja.py -> 14 passed; dbt jinja/filter tests + tests/utils/test_yaml.py pass.
• ruff check, ruff format --check, mypy sqlmesh/utils/jinja.py clean.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO

[StuffbyYuki]

@anxkhn Thanks for your work on this!

Optional (non-blocking):

• Add a short note in docs/guides/configuration.md (near the env_var examples) showing {{ env_var('BIGQUERY_KEY_B64') | b64decode }} for base64-encoded secrets.
• Consider a test that uses env_var + b64decode together (mock/set env) to match the real-world use case.
• A brief docstring on b64decode noting it returns UTF-8 text (intended for JSON/string secrets, not arbitrary binary) would help future users.

[JohnSchlerf]

This is amazing. Thank you!