docs: add YAML example to PromptBuilder documentation

Author: ritikraj2425

docs-website/docs/pipeline-components/builders/promptbuilder.mdx

@@ -188,6 +188,45 @@ result = p.run({"prompt_builder": {"documents": documents, "query": question}})
 print(result)
 ```
 
+#### In YAML
+
+This is the YAML representation of the RAG pipeline shown above. It renders a custom prompt template by filling it with the contents of retrieved documents and a query, then sends the rendered prompt to a generator.
+
+```yaml
+components:
+  llm:
+    init_parameters:
+      api_base_url: null
+      api_key:
+        env_vars:
+        - OPENAI_API_KEY
+        strict: true
+        type: env_var
+      generation_kwargs: {}
+      http_client_kwargs: null
+      max_retries: null
+      model: gpt-4o-mini
+      organization: null
+      streaming_callback: null
+      system_prompt: null
+      timeout: null
+    type: haystack.components.generators.openai.OpenAIGenerator
+  prompt_builder:
+    init_parameters:
+      required_variables: null
+      template: "\n    Given these documents, answer the question.\\nDocuments:\n\
+        \    {% for doc in documents %}\n        {{ doc.content }}\n    {% endfor\
+        \ %}\n\n    \\nQuestion: {{query}}\n    \\nAnswer:\n    "
+      variables: null
+    type: haystack.components.builders.prompt_builder.PromptBuilder
+connection_type_validation: true
+connections:
+- receiver: llm.prompt
+  sender: prompt_builder.prompt
+max_runs_per_component: 100
+metadata: {}
+```
+
 #### Changing the template at runtime (Prompt Engineering)
 
 `PromptBuilder` allows you to switch the prompt template of an existing pipeline. The example below builds on top of the existing pipeline in the previous section. We are invoking the existing pipeline with a new prompt template:

releasenotes/notes/add-yaml-promptbuilder-docs-5a570b3010d0e1bf.yaml

@@ -0,0 +1,32 @@
+---
+highlights: >
+    Replace this text with content to appear at the top of the section for this
+    release. The highlights might repeat some details that are also present in other notes
+    from the same release, that's ok. Not every release note requires highlights,
+    use this section only to describe major features or notable changes.
+upgrade:
+  - |
+    List upgrade notes here, or remove this section.
+    Upgrade notes should be rare: only list known/potential breaking changes,
+    or major changes that require user action before the upgrade.
+    Notes here must include steps that users can follow to 1. know if they're
+    affected and 2. handle the change gracefully on their end.
+features:
+  - |
+    List new features here, or remove this section.
+enhancements:
+  - |
+    List new behavior that is too small to be
+    considered a new feature, or remove this section.
+issues:
+  - |
+    List known issues here, or remove this section. For example, if some change is experimental or known to not work in some cases, it should be mentioned here.
+deprecations:
+  - |
+    List deprecations notes here, or remove this section. Deprecations should not be used for something that is removed in the release, use upgrade section instead. Deprecation should allow time for users to make necessary changes for the removal to happen in a future release.
+security:
+  - |
+    Add security notes here, or remove this section.
+fixes:
+  - |
+    Add normal bug fixes here, or remove this section.