Lightweight / core-only google-adk install for embedded use

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

Installing `google-adk` currently pulls in the full web / dev / observability stack as *required* dependencies (e.g. `fastapi`, `starlette`, `uvicorn`, `google-cloud-aiplatform`, `google-genai`, `opentelemetry-sdk`, etc.), even if you only need to embed agents into an existing Python application.

In my case, ADK agents run inside an existing web app (for example, a Flask application). The app already owns the HTTP server, routing, deployment and observability. I only need the agent graph + tools as an in-process Python library, but `pip install google-adk` still brings in everything needed for the API server, Dev UI and evaluation tooling. This increases container size, import time and the overall attack surface for production deployments.

**Describe the solution you'd like**

Provide an officially supported lightweight / core-only installation option, for example:

- A separate `google-adk-core` distribution that includes only:
- core agent framework (agents, tools, runners, sessions, basic model integrations);
- no FastAPI/Uvicorn, no Dev UI, no OpenTelemetry exporters and no extra Google Cloud clients unless strictly required;

**or**

- An extra such as `google-adk[minimal]` / `google-adk[runtime]` that installs only what is needed to:
- define agents and tools in Python; and
- run them programmatically inside another process.

The current `google-adk` package could remain “batteries included” for users who want the full stack.

**Describe alternatives you've considered**

- Running ADK as a separate service (for example, on Cloud Run) and calling it over HTTP from the main app. This works technically, but adds network latency and operational complexity when the goal is just to call an agent from in-process Python.
- Installing `google-adk` with `--no-deps` and maintaining a curated dependency list manually. This is fragile and easy to break as the project evolves.
- Forking `adk-python` and maintaining a private stripped-down build. This diverges from upstream and is hard to keep in sync.

None of these options feels like a good fit compared to an officially supported lightweight / runtime-only installation mode.

**Additional context**

The docs describe ADK as a deployment-agnostic framework, and examples already show it running in containerized environments like Cloud Run. In those scenarios, having a smaller dependency surface (when ADK is embedded into an existing service) would help with security, cold starts and dependency management.

Environment sketch:

- `google-adk`: ~1.18.x (recent 1.x releases)
- Python: 3.12 / 3.13
- Deployment: Docker containers (e.g. Cloud Run, Kubernetes)
- Application: existing Python web service where ADK agents are only a small embedded part of the overall system.

Related but different: #2657 discusses dependency constraints with FastAPI and other frameworks, not a smaller, runtime-only install.