OIDC Authentification

**Is your feature request related to a problem? Please describe.**

Currently we have to hand out credentials to developers which they store on hard-drive to access private repositories. This makes boarding and off-boarding employees annoying and decreases the security as tokens can be easily be stolen and give other people without actual permit.

**Describe the solution you'd like**

A new `oidc` auth type in `auth.json` that supports three grant types:

- **Authorization Code (browser flow, default)** -- for developer workstations. Composer opens the browser, the user logs in, and Composer receives a token via a local callback. Refresh tokens are used to avoid repeated logins.
- **Client Credentials** -- for service accounts and CI with static secrets.
- **Token Exchange** -- for CI environments with OIDC (GitHub Actions, GitLab CI, etc.). A CI-provided JWT is exchanged for an access token at the registry's token endpoint.

Configuration supports OIDC discovery via `issuer-url` (fetches `.well-known/openid-configuration`), with `authorization-url`, `token-url` and `audience` as optional overrides.

Multiple configs per domain are supported as an array, with an `if` condition for environment-based selection (e.g., use token exchange on CI, browser flow locally):

> [!NOTE]
> You want to use Azure Login on local developer machine, but use GitHub Actions OIDC on CI/CD

```json
{
"oidc": {
"packages.example.com": [
{
"preset": "github-actions"
},
{
"issuer-url": "https://login.microsoftonline.com/.../v2.0",
"client-id": "composer-public-client"
}
]
}
}
```

Named presets (e.g., `github-actions`, `gitlab-ci`) are shortcuts that expand into the appropriate `if` condition and subject token source. For example, `"preset": "github-actions"` implies `"if": "env:ACTIONS_ID_TOKEN_REQUEST_URL"` and knows how to fetch the JWT from GitHub's token service. Users can also write conditions manually for custom CI environments:

```json
{
"if": "env:MY_CI_OIDC_TOKEN",
"grant-type": "token-exchange",
"subject-token-env": "MY_CI_OIDC_TOKEN",
"issuer-url": "https://idp.example.com/realms/myrealm"
}
```

We filter down by the if the allowed providers to end to just have one provider to try.

## Config lives in the Packages API

Second idea, the package server itself could provide all possible auth methods to simplify on client side the authentification.

```json
{
"oidc": {
"packages.example.com": {}
}
}
```

or (when multi tenant, to reocongize who are u)

```json
{
"oidc": {
"packages.example.com": {
"tenant": "xxx"
}
}
}
```

This extracts from `/.well-known/composer/oidc-configuration` and that returns a similar JSON from first idea and the client does the authentification handling based on that.

**Additional context**

- GitHub Dependabot supports also OIDC, this should somehow work together: https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot#using-oidc-for-authentication

I opend this issue for discussion before doing the actual implementation, to gather feedback.