RFC(maa-value): Decouple I/O from UserInput via Extension Trait and abstract Prompting

### Why

Currently, the `UserInput` trait in `maa-value` contains the `.value()` helper method which hardcodes standard I/O (`std::io::stdin().lock()` and `std::io::stdout()`). While convenient for CLI usage, this tightly couples the core configuration resolution logic to standard console I/O, preventing its reuse in non-interactive environments like RPC services or GUI wrappers.

Furthermore, even the underlying `.ask(writer, reader)` method, while generic over `Write` and `BufRead`, is fundamentally optimized for a **stream-based console interaction model** (e.g., printing prompts and blocking on a newline). This model is not straightforward or ergonomic for modern async/event-driven architectures like RPC or GUI. In such environments, input is typically requested by sending a structured message (prompt metadata) to a client and asynchronously receiving a typed payload back, rather than interacting with continuous text streams.

### Expected Behavior
We should decouple the interactive querying logic from the core value resolution, treating standard I/O streams as just one specific implementation.

**Suggested Refactoring Steps:**

1. **Move `.value()` to an Extension Trait (`UserInputStdioExt`):**
- Remove `.value()` from the core `UserInput` trait in `maa-value`.
- Create a new extension trait `UserInputStdioExt` within `maa-cli` (or a dedicated standard I/O integration layer) that provides the `.value()` method specifically for standard console interactions.
- This ensures `maa-value` becomes a pure logic library with zero assumptions about the execution environment, while preserving the ergonomic `.value()` calls for the CLI.

2. **Abstract the Interaction Model (Future-proofing `ask`):**
- Instead of hardcoding `Write` and `BufRead` into the core trait, consider introducing an abstraction like a `PromptHandler` or `InteractionContext` trait that gets passed down during the `resolve()` process.
- The framework would call something like `context.request_input(prompt_metadata)` which returns a typed value.
- `maa-cli` would implement this `Context` using standard I/O.
- An RPC server could implement this `Context` by suspending the resolution, sending a structured message to the client, and resuming upon receiving the payload.

### Additional Context
This architectural limitation was identified during the review of the `refactor/resolved_maa_value` branch. Implementing these changes will ensure `maa-value` is a truly environment-agnostic core library, ready for broader integrations beyond the CLI.

Start by locating the UserInput trait and its value() and ask(writer, reader) methods in the maa-value crate, then inspect the maa-cli integration points. Review the refactor/resolved_maa_value branch context before deciding how the interaction abstraction should work. Done means standard I/O is isolated from maa-value while CLI behavior remains available through an extension or integration layer.

Written by the indexing model from the issue text.