jaeger_query: support serving UI assets from an archive, not just a directory

The jaeger_query extension can serve the UI from a filesystem path via ui.assets_path:

// cmd/jaeger/internal/extension/jaegerquery/internal/static_handler.go
assetsFS := ui.GetStaticFiles(logger)
if qOpts.UIConfig.AssetsPath != "" {
    assetsFS = http.Dir(qOpts.UIConfig.AssetsPath)
}

Because it uses http.Dir, assets_path must be a directory. A custom Jaeger distribution that serves the UI from disk (rather than embedding it) must therefore unpack the published jaeger-ui assets.tar.gz into a directory at image-build time before the binary can use it.

Proposal

Let the existing ui.assets_path accept the published assets.tar.gz directly, in addition to a directory — a single property, no new option. When the path is a regular file (not a directory) whose name ends in .tar.gz, serve it via an fs.FS over gzip+tar (both stdlib); otherwise keep the current http.Dir behavior. The suffix plus the not-a-directory check is enough to disambiguate — no magic-byte sniffing.

Same property, either form:

extensions:
  jaeger_query:
    ui:
      assets_path: /var/lib/jaeger/ui          # directory (current behavior)
      # assets_path: /var/lib/jaeger/assets.tar.gz   # archive (proposed)

This removes the unpack step for custom builds and matches how the assets are distributed on the jaeger-ui releases page.

Testing

Covered by a unit test, no e2e wiring needed. cmd/jaeger/internal/extension/jaegerquery/internal/static_handler_test.go already exercises AssetsPath against a directory fixture (AssetsPath: "fixture"); add a parallel case that points AssetsPath at a fixture.tar.gz (a gzipped tar of the same fixture) and asserts the handler serves identical content — plus an error case for a malformed/unreadable archive. (The Jaeger backend repo has no UI-serving e2e; UI behavior is tested in the jaeger-ui repo.)