[dagster-dbt][refactor] Clean up multi-asset creation

[OwenKephart]

Summary & Motivation

We have a bunch of complex logic going on here, purely because we are not taking advantage of the features around passing specs into @multi_asset

Crucially, before this change, we were manually creating internal_asset_deps, AssetIns, and AssetOuts independently, alongside juggling a bunch of different dictionaries to keep track of it all.

Now, I've created a single get_asset_spec method. Once we're ready, this can essentially be copy-pasted into the DagsterDbtTranslator class once we're ready, but for now this is purely-internal construct.

The only change in the constructed object is that we no longer have control over the generated output names for each key, and instead they are automatically generated using AssetKey.to_python_identifier. This is the cause of the updated tests.

I judge this is totally fine -- the output names are not actually user-facing in this context, it's just framework code that needs to handle this mapping (and this framework code actually gets a bit nicer as well)

How I Tested These Changes

Changelog

NOCHANGELOG

[OwenKephart]

• [dagster-dbt] Spec-ify dbt cloud integration #26662
• [dagster-dbt][refactor] Clean up multi-asset creation #26614 👈 (View in Graphite)
• [dagster-dbt][refactor] Use AssetOut.from_spec() to create AssetOuts for dbt_assets decorator #26613 : 1 other dependent PR (#26625 )
• allow different PartitionsDefinitions within an AssetsDefinition #23824
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.