Create connections for additional providers

### Area

Configuration (parameters, projects)

### Problem or use case

Connection creation currently supports GitHub App and Docker registry connections. Users of other providers must create connections in the TeamCity UI or use raw REST calls. Authorization support for a provider does not mean the CLI can create its connection.

### Proposed solution

Add providers independently, based on a concrete user need. Candidates include GitLab (hosted/self-managed), Bitbucket Cloud, GitHub OAuth/Enterprise, AWS, and Azure DevOps. Other providers can be proposed with their intended use case; this is not a commitment to implement every provider.

For each provider:
- Confirm supported TeamCity versions, persisted properties, and authentication flow against a working connection. Do not copy unverified property tables.
- Provide required fields, secret prompts/stdin, useful non-interactive errors, and JSON output using existing command conventions.
- Verify creation, the applicable authorization flow, and actual use by a VCS root or consuming build feature. Test invalid input without exposing secrets.

GitLab connection metadata is present on cli.teamcity.com, but no new provider creation or external OAuth flow was tested during grooming. Choose the first provider before implementation.

### Alternatives considered

Create connections through the UI or `teamcity api`. A generic unchecked property writer would still leave provider-specific setup and validation to callers.

### Contribution

- [ ] I'd be willing to submit a PR (once it's `status:finalized`)

No implementation files, tests, or entry points are named. First choose one provider and verify its TeamCity versions, persisted properties, authentication flow, and working connection; then trace the existing connection-creation command conventions. Done means validated creation, authorization and consumer use, with secret-safe invalid-input handling and JSON output tests.

Written by the indexing model from the issue text.