[Feature]: Support Declarative Multi-Agent & Multi-Provider Configuration in Spring Boot

## The Problem

Currently, AgentScope-Java's Spring Boot Auto-Configuration only supports declaring a **single Agent instance**. This is a major blocker for real-world business scenarios where multiple agents are needed to handle different tasks.

We lack a declarative way to:
- Configure **multiple LLM providers** (OpenAI, DashScope, Anthropic, Gemini, Ollama, etc.) simultaneously.
- Define **multiple models** under each provider with independent parameters.
- Declare **multiple agents** that reference different models and carry different system prompts.
- Dynamically **resolve agents by name** at runtime without manual Spring Bean injection.
- Register **custom tools** and reference them in agent configurations by name.

Without this, every team has to build their own integration layer, leading to duplicated effort and inconsistency.

## Proposed Solution

Native Spring Boot `@AutoConfiguration` / `@ConfigurationProperties` support that enables developers to define Providers, Models, and Agents purely through YAML configuration:

agentscope:

  providers:

    my-openai:

      name: "My OpenAI"

      api-key: "sk-xxx"

      provider-type: "openai"

      base-url: "https://api.openai.com/v1/"

      models:

        gpt-4o:

          name: "GPT-4o"

          model-name: "gpt-4o"

          generate-options:

            temperature: 0.7

            max-tokens: 4096


  agents:

    translator:

      name: "Translator"

      model: "my-openai:gpt-4o"

      sys-prompt: "You are a translator."

      max-iters: 10

    analyzer:

      name: "Analyzer"

      model: "my-openai:gpt-4o"

      sys-prompt: "You are an analyst."

      toolkit:

        - my-tool

Additionally, provide a simple static API to resolve agents by name at runtime:

ReActAgent agent = AgentRegistry.resolve("translator");

And support registering custom tools to be referenced by name in agent config:

AgentRegistry.registerTool("my-tool", new MyCustomTool());

## Alternatives Considered

- Writing manual Java code for each agent.
- Wrapping agents behind custom service layers.

Both approaches require significant boilerplate and become hard to maintain as the number of providers or agents grows.

## Additional Context

N/A