[Feature] Support passing `deployment_type` values to `defer-env-id`

### 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

### Which version of dbt is this feature for?

dbt v2.x (Core or Fusion)

### Describe the feature

We support passing an environment ID as the argument for `defer-env-id`, but I believe we should support being able to pass the `deployment_type` as a more human friendly option.

```
name: my_project

dbt_cloud:
defer-env-id: production | staging | 123456

# or instead of overloading defer-env-id
defer-env: production | staging
```

This would aid in customers not having to keep this ID in sync with their `dbt_project.yml` as their cloud project evolves, and for those that scaffold/template their dbt projects across many, it prevents a manual or remote state lookup to get the ID.

Technical considerations:
- This would add a simple API call to resolve the environment ID whenever download manifest is triggered, skips if a specific ID is passed
- It's probably better to create a separate key for this like `defer-env` instead of overloading `defer-env-id`. The tradeoff is we have to handle for cases when both `defer-env` and `defer-env-id` are passed, which is probably more common than not given this value can live in the `dbt_project.yml` and `dbt_cloud.yml`

### Describe alternatives you've considered

There really aren't any, at some point somewhere the correct environment ID has to be resolved, whether that's manual or not.

### Who will this benefit?

Any platform user that does local CLI development, but more importantly platform teams that operate large dbt platform estates with many projects, as scaffolding dbt projects is very common in this segment.

### Are you interested in contributing this feature?

Yes, opening with an associated draft PR.

### Anything else?

_No response_