Feat: dbt cli skeleton

[erindru]

Adds a very basic skeleton for creating a CLI that takes input in the form of existing dbt core CLI commands and translates them to the SQLMesh equivalent.

It doesn't do much yet but i've raised this PR to demonstrate the approach i'm thinking and also in the spirit of smaller, more focused PR's vs a big dump.

The goal here is also to provide some initial hooks to help multiple developers build out functionality in parallel.

Key points:

• New CLI entrypoint, sqlmesh_dbt, with the intention of being able to one day alias dbt=sqlmesh_dbt and still have things work
• It's currently in its own top-level package to avoid the delay that occurs when importing anything from the sqlmesh package. This allows it to start outputting to the console immediately and defer loading SQLMesh until later.
• I added a basic test skeleton that is based around the public jaffle_shop_duckdb project
• I also updated ruff/mypy/setuptools etc to pick up the new top-level package

If you clone the jaffle shop_duckdb project, you can, with zero changes to anything in that project:

$ sqlmesh_dbt list
Loading engine ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  
[WARNING] DuckDB does not support concurrency - setting threads to 1.
05:11:20  Registered adapter: duckdb=1.9.2
main.orders
main.customers
main.stg_payments
...SNIP..

(note: I only added this because it was helpful in investigating why selectors weren't matching)

and

$ sqlmesh_dbt run
Loading project ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 
05:13:03  Registered adapter: duckdb=1.9.2

`prod` environment will be initialized

..SNIP... usual SQLMesh output for a forward-only no-prompts plan

[izeigerman]

effective_from means something different, let's use start instead or not pass anything at all

[izeigerman]

I don't think we should not set this explicitly

[izeigerman]

Instead of doing this I'd suggest extending sqlmesh_config with the start date and hardcode the start date at sqlmesh init time.

[erindru]

I'll do this in a follow-up PR. To summarize our conversation:

• We dont touch any existing dbt file like dbt_project.yml
• We check for a file called sqlmesh.yaml in the root of the DBT project
• If it exists, we read directives like the start date from it and it generally follows the same format as SQLMesh's existing config.yaml file
• If it doesn't exist, we do an "automatic init" to create it and stamp the start date as yesterday_ds() so it can take effect on subsequent invocations

This approach also provides a place to store other configuration in future, such as the virtual data environment mode

[erindru]

#5132

[izeigerman]

is this needed?

[erindru]

No, it's leftover from when I was experimenting with pytest marks. Will remove it