[MCP Prompt] Implement support for MCP prompts

Implement support for MCP prompts in the Java worker. This feature allows functions to expose prompt templates that MCP clients can discover, list, and invoke with arguments — enabling structured interactions with language models.

#### Background

The MCP specification supports prompts as a way for servers to expose reusable prompt templates. Clients can discover available prompts via `prompts/list` and invoke them via `prompts/get`, optionally providing arguments. Prompts return a list of messages that can include text, images, audio, or embedded resources.

**MCP Specification:** https://modelcontextprotocol.io/specification/2025-06-18/server/prompts

**Reference Implementation:**
- Host-side: https://github.com/Azure/azure-functions-mcp-extension/pull/210
- Worker-side (.NET): https://github.com/Azure/azure-functions-mcp-extension/pull/211

#### Host Extension Contract

##### 1. Function Metadata (Binding JSON)

The worker must report prompt functions with the following trigger binding metadata:

```json
{
"type": "mcpPromptTrigger",
"direction": "in",
"name": "",
"promptName": "",
"title": "",
"description": "",
"promptArguments": "",
"metadata": "",
"icons": ""
}
```

The `promptArguments` field is a JSON-serialized array of argument definitions:
```json
[
{
"name": "code",
"description": "The code to review",
"required": true
},
{
"name": "language",
"description": "The programming language",
"required": false
}
]
```

##### 2. Invocation Context

When a prompt is invoked (`prompts/get`), the host sends the trigger binding data as a JSON-serialized `PromptInvocationContext`:

```json
{
"name": "code_review",
"arguments": {
"code": "def hello(): ...",
"language": "python"
},
"sessionid": "",
"transport": {
"sessionId": "",
"baseUrl": ""
}
}
```

- `name`: The prompt name being invoked
- `arguments`: A flat `Dictionary` — all argument values are strings
- `sessionid`: May be null
- `transport`: May be null

##### 3. Return Value Contract

The host extension expects the worker to return **a string** value. Two formats are accepted:

**Option A: Plain string** — the host automatically wraps it in a single `PromptMessage`:
```json
{
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": ""
}
}
]
}
```

**Option B: JSON-serialized `GetPromptResult`** — the host deserializes and uses it directly. This is detected by checking if the deserialized object has `messages` with count > 0 OR `description` is not null.

```json
{
"description": "Optional prompt description",
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "Please review this Python code:\n\ndef hello():\n print('world')"
}
}
]
}
```

Supported message content types per MCP spec:
- `TextContentBlock` (`type: "text"`, `text: string`)
- `ImageContentBlock` (`type: "image"`, `data: base64-string`, `mimeType: string`)
- `AudioContentBlock` (`type: "audio"`, `data: base64-string`, `mimeType: string`)
- `EmbeddedResource` (`type: "resource"`, `resource: { uri, mimeType, text|blob }`)

#### Key Considerations

1. **Prompt arguments are always strings** — unlike tool properties which can have typed JSON schemas, prompt arguments are flat string key-value pairs.

2. **Simplest path:** Return a plain string from the function. The host handles wrapping it in a `PromptMessage` with `role: "user"`.

3. **Rich responses:** For multi-message prompts, mixed roles (user/assistant), or non-text content (images, audio, embedded resources), return a JSON-serialized `GetPromptResult`.

4. **Follow existing tool patterns** — The prompt implementation should follow the same worker patterns established for MCP tools (trigger binding, invocation context, return value handling).

5. **Metadata support** — The `metadata` and `icons` fields are optional JSON strings that the host passes through to MCP clients. The worker should support declaring these in the function definition.