Support resource outputs as managed Bitwarden secret values

### Related to an existing integration?

Yes: `CommunityToolkit.Aspire.Hosting.Bitwarden.SecretManager`.

### Overview

Let an Aspire resource output supply a managed Bitwarden secret. For example, a provisioned service can produce a connection string during deployment.

Keep `AddSecret(name)` for user-provided values, including existing parameter configuration, defaults, prompts, and missing-input prefill from Bitwarden. Keep `GetSecret(name/id)` read-only.

Add an expression overload for managed reference secrets. Aspire owns the destination key, while another resource supplies its value. An explicit `Parameters:{parent}-{secret}` value overrides the expression. Otherwise, each reconciliation evaluates the expression again. Failed or missing output must not fall back to a stored destination value. Generated output must not become a saved input override.

### Usage example

```csharp
// Current usage with AddSecret(name): the secret value is provided as Parameters:bitwarden-api-key
var apiKey = bitwarden.AddSecret("api-key");

// PROPOSAL: an overload accepts a ReferenceExpression that provides the secret value
var dbConStr = bitwarden.AddSecret("database", database.Resource.ConnectionStringExpression);
```

The existing Bitwarden resource supplies `bitwarden`. The producing database resource supplies `database`. Deployment steps must order the producer before Bitwarden reconciliation.

### Breaking change?

The proposal preserves `BitwardenSecretResource : ParameterResource` and existing convenience calls. Input precedence and repeated parameter-processing behavior need review.

### Alternatives

- Require callers to resolve outputs and run the Bitwarden CLI themselves.
- Replace parameter inheritance with separate input and destination resources. This changes the existing resource model and parameter APIs.
- Add source-specific paths to the writer. This duplicates behavior that belongs in value preparation.

### Additional context

Providers prepare the inherited parameter state. Base getters, interface getters, and the common Bitwarden writer read that same state.

https://github.com/microsoft/aspire/pull/18108 is a prerequisite for a clean implementation. Its proposed optional parameters and public value/error setters replace the private-state access needed on Aspire 13.5. Lifecycle ordering and fresh-value tests remain necessary after those APIs become available.

A draft implementation uses Aspire internals to exercise the contract now. It is for design review, with prerequisite work pending.

### Help us help you

Yes, I would like to contribute the implementation.

Start with CommunityToolkit.Aspire.Hosting.Bitwarden.SecretManager, BitwardenSecretResource, and the AddSecret/GetSecret APIs. Review prerequisite PR #18108 and the provider value-preparation state before assessing lifecycle ordering. Done requires fresh-value and lifecycle-ordering coverage while preserving existing parameter behavior and preventing failed outputs from falling back to stored values.

Written by the indexing model from the issue text.