[Feature] Support custom target-scoped configuration in profiles.yml

### Is this your first time submitting a feature request?

- [x] I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
- [x] I have searched the existing issues, and I could not find an existing issue for this feature
- [x] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

### Describe the feature

I know,
> profiles.yml is understandably treated as connection-oriented configuration. This proposal keeps that boundary intact by requiring all user-defined metadata to live under an explicit params: namespace rather than introducing arbitrary top-level keys.

Today, `target.` in Jinja only includes fields explicitly declared on an adapter's `Credentials` dataclass. Any unknown keys in `profiles.yml` are accepted during parsing, but discarded before the target context is built.

That makes it difficult to associate target-specific metadata with a target and reuse it from `dbt_project.yml`, model configs, or macros.

Proposal: add a reserved `params:` mapping on profile targets and expose it as `target.params` in Jinja.

```yaml
# profiles.yml
my_profile:
outputs:
dev:
type: fabricspark
...
params:
workspace_name: "vd-dbt-fabricspark-dev"
region: "canadacentral"

prod:
type: fabricspark
...
params:
workspace_name: "vd-dbt-fabricspark-prod"
region: "westus"
```

```yaml
# dbt_project.yml
models:
+workspace_name: "{{ target.params.workspace_name }}"
```

```sql
-- models/my_model.sql
{{ config(region = target.params.region) }}
```

This provides a lightweight, adapter-agnostic way to attach arbitrary metadata to a target without requiring adapter changes for every new use case.

Implementation surface should be very small:

```python
params: Dict[str, Any] = field(default_factory=dict)
```

added to the base `Credentials` dataclass (or whichever structure feeds the target context), plus pass-through into `target`.

No adapter-specific implementation required.

### Describe alternatives you've considered

### Adding adapter-specific fields

Adapters can add inert fields like:

```python
workspace_name: Optional[str]
```

purely so users can access them through `target.workspace_name`.

This works, but requires adapter-specific code and release cycles for values that are often unrelated to the adapter's connection layer. It also unnecessarily expands credentials classes with user metadata.

### `env_var`

Environment variables work, but they move target metadata outside the target definition itself.

For values that logically belong to a target ("when using `prod`, use this workspace"), `profiles.yml` is a more natural source of truth than external shell state.

### `vars` keyed by `target.name`

```yaml
vars:
workspace_names:
dev: "dev_ws"
prod: "prod_ws"
```

```yaml
models:
+workspace_name: "{{ var('workspace_names')[target.name] }}"
```

This duplicates environment information across files and requires manual synchronization whenever targets change.

### Project macros / dispatch

Possible, but significantly heavier than the use case requires.

### Who will this benefit?

* Users managing per-target metadata such as workspace, region, cluster, project, labels, or routing information
* Adapter authors who currently receive requests to expose arbitrary fields solely so they become accessible via `target.*`
* Multi-environment deployments where downstream configs and macros need lightweight target-scoped metadata
* Workflows involving clone/defer/cross-environment operations where targets differ by attributes outside the connection layer

### Are you interested in contributing this feature?

Yes

### Anything else?

* Purely additive; does not replace existing target fields
* `params` reads naturally in Jinja (`target.params.workspace_name`)

This came up while working on cross-workspace clone support in [dbt-fabricspark](https://github.com/microsoft/dbt-fabricspark?utm_source=chatgpt.com), where targets need workspace-level metadata exposed to model configuration even though the adapter itself does not use those values for authentication or connection handling.