Allow dynamic environment names

### Details

We're using this action to deploy to dynamic environments, e.g. `https://feature-1234.example.com` where `feature-1234` is the environment name. We use a branch slug to create the env name or allow the user to enter his one via `.deploy to some-env`.

However I need to hack the action to allow these names by doing some github workflows magic, like:

```yaml
# Allow to use the custom env name if provided via command (parsed from comment)
- name: Final Env Name
id: env
run: |
name=${{ steps.custom-env.outputs.result }}

- uses: github/branch-deploy@v9.9.1
id: bot
with:
trigger: ".deploy"
environment: ${{ steps.env.outputs.name }}
# Don't restrict the list of environments to deploy to, to allow usage of free-name environments
environment_targets: ${{ steps.env.outputs.name }},staging,canary
```

It would be very useful to accept a falsey value for `environment_targets` (or some wildcard chars, or a regex) to allow dynamic env names.

Another option would be to provide an input to skip the `environment_targets` validation for the action.

Thanks.

Start by tracing how the action reads and validates the environment_targets input, then inspect the deployment environment selection entry point. Compare the requested falsey, wildcard, regex, or skip-validation behaviors and determine which one fits the existing input handling. Done means dynamic names such as feature-1234 can deploy without weakening explicitly configured environment restrictions.

由索引模型根据 Issue 内容生成。