Add initial scaffold for nl trace query parsing

[Nischal1425]

Which problem is this PR solving?

• Part of AI-Powered Trace Analysis with Local LLM Support #7832 (AI-Powered Trace Analysis with Local LLM Support)

Description of the changes

• Introduces an initial scaffold for a natural language -> trace query
  translation layer.
• Adds a dedicated nlquery package collocated with the jaegerquery
  extension.
• Defines a constrained result type that reuses existing
  TraceQueryParams to ensure deterministic behavior.
• No runtime behavior is changed in this PR.

How was this change tested?

• Not applicable at this stage (structural scaffold only).
• Unit tests and functional behavior will be added in follow-up PRs.

Checklist

• I have read the contributing guidelines
• I have signed all commits
• I have added unit tests for the new functionality (planned next)
• I have run lint and test steps successfully (not required yet for scaffold)

[kunalsanga]

This scaffold aligns well with the mentorship goal of keeping things deterministic and non-AI-first.

One thought for future extensibility: would it make sense to define a small interface (e.g. IntentExtractor or similar) here, so that this rule-based parser and a future AI-backed extractor can be swapped without touching the query path?

[Nischal1425]

Thanks for the suggestion, and i agree this make sense.
for this initial PR i intentionally kept the scaffold concrete to validate placement and data flow first. Once the contract is exercised a bit more for example, with LangChainGo-backed extraction, introducing a small interface like IntentExtractor to swap implementations without touching the query path sounds like a good next step