Move to adapter-specific installations of dbt (Snowflake)

_Note: In addition to the below description, this proposal is intended to resolve https://gitlab.com/meltano/meltano/-/issues/3098+_

--------------------------

The dbt docs are now recommending users to install an adapter-specific version of dbt rather than the generic `dbt` or `dbt-core` packages. This is true even for mainstream packages like Postgres. https://docs.getdbt.com/dbt-cli/install/pip

## Proposal: use an adapter-specific plugin name

These examples all use Snowflake as an example, but we would support 4 adapters at launch (same as supported today):

- `dbt-bigquery`
- `dbt-redshift`
- `dbt-postgres`
- `dbt-snowflake`

### Installation

```console
> meltano add transformer dbt-snowflake
Installing `dbt-snowflake`...
Install completed.
```

### New user experience 

1. A new user installing `dbt-snowflake` for the first time, would following the installation instructions above: `meltano add transformer dbt-snowflake`.
2. After installing the dbt-snowflake transformer, they'd have 3 auto-created profiles in the auto-installed `profiles.yml` for `dbt`: 'prod', 'beta', and 'dev' - defaulting to `dev`.
3. Without any changes to `profiles.yml`, without setting any environment variables, and without needing to invoke a tap or target, they'd have their dbt environment configurable via the `config:` block in the `dbt-snowflake` plugin definition, inside `meltano.yml`.

### Migration experience

1. An existing Meltano user who already has the dbt plugin installed will perform a new install: `meltano install transformer dbt-snowflake`.
2. This will keep their existing `meltano.yml` file as-is and will likewise not affect their existing profiles file.
3. They will now have a new `dbt-snowflake` plugin and a new profiles file: `${MELTANO_PROJECT_ROOT}/transforms/profiles/snowflake/profiles.yml`.
4. The `dbt-snowflake` plugin will point to the _new_ profiles directory and the old `dbt` plugin will still point to the _old_ profiles directory.
5. As a one time config, the user will set any necessary config in `meltano.yml` in order to properly seed dbt profile info with the `dbt-snowflake` settings config.
6. Whenever the user is ready, they may optionally uninstall their older `dbt` plugin entry and delete the older `profiles.yml` file. (Side-by-side execution should work in the meanwhile.)

## As related to #3098 and missing special environment variables:

If we do this right, it's very likely we can also solve #3098 at the same time as launching new adapter-specific dbt plugins.

- All env variables currently injected by the `extractor` or `loader` will instead be declared as `settings` registered with `env:` mappings, with their values set via standard `config:` blocks.
    - Aka: No "magic" environment variables are needed, all settings go through through plugin config.
- Migrating to adapter-specific dbt entries comes along with new adapter-specific `profiles.yml` files.
- The migration from generic `dbt` plugin to the adapter specific ones is a one-time breaking change which allows us to flush the tech debt without breaking existing installations using the legacy `dbt` plugin definition.

### Messaging re `meltano run dbt:run`

After releasing this, we'd recommend users to migrate to adapter-specific dbt plugins if they want to use `dbt:run` and other dbt-related invocations as part of `meltano run`. (Hence, a resolution to #3098.) This would be a one time and _voluntary_ breaking change, after which they'd (1) be on the latest version of dbt and (2) have a more resilient and robust `dbt` experience in Meltano overall.

## Python updates under the hood

Internally:

Any logic internal to Meltano core which is hardcoded to the `dbt` plugin name would need to be replaced with logic that accepts plugins with the name `dbt*`.

## Pointing to adapter-specific profiles folders

Important to note is that dbt only accepts overrides for the _directory_ containing `profiles.yml`, and does not allow you to point directly to a single file. For this reason I'm proposing the files bundles have `profiles.yml` files with paths in the format `${MELTANO_PROJECT_ROOT}/transform/profiles/<adapter>/profiles.yml` and then `DBT_PROFILES_DIR` for `dbt-snowflake` (for instance) would default to the directory `${MELTANO_PROJECT_ROOT}/transform/profiles/snowflake`.

## Accompanying `files` Bundles:

This should be reviewed and tested along with:

- `files-dbt-biquery`: TODO
- `files-dbt-postgres`: TODO
- `files-dbt-redshift`: TODO
- `files-dbt-snowflake`: https://gitlab.com/meltano/files-dbt-snowflake/-/merge_requests/2

## Usability: Invocation via `dbt:run` vs `dbt-snowflake:run`

If we install adapter-specific plugins as distinct `transformer` plugins, presumably this also makes their invocation slightly more verbose.

- On the 'pros' side: this makes it very simple to support multiple dbt adapters in a single project, with no ambiguity. For instance: `dbt-snowflake:run` and `dbt-athena:run` would both "just work".
- On the 'cons' side: invocation is more wordy, and any sample code like `meltano run dbt:run dbt:test` is no longer copy-paste-able to other projects.

@kgpayne's suggestion in #3220+ could mitigate this. Ideally, if dev time were not a factor, we'd probably alias the first dbt installation as 'dbt' and then subsequent installations would _not_ be aliased.

## Previous proposals:

<details><summary>Click to expand</summary>

### Option 1: Prompt during installation. (Replaced with 1B)

<details><summary>Click to expand</summary>

```console
> meltano add transformer dbt

Please select from the following list:
1. Redshift
2. Snowflake
3. Postgres
4. BigQuery
5. SQLite

To install more than one adapter, use commas as separators.

> 5

Installing `dbt-sqlite`...
Install completed.
```

```console
> meltano add transformer dbt --adapter=snowflake
Installing `dbt-snowflake`...
Install completed.
```


### Option 2: Read from meltano environment.

If we add the ability to specific a `primary_loader` to each environment, we can then check if the required adapter is installed in the `dbt` venv, installing it if not yet added. This could also be used to select or generate a proper profile from the target definition (more discussion about auto-managed profiles in #3104).

</details>

Story points: 8.0