Tempo / Trace Viewer: Implements deep linking to spans

[erin-noe-payne]

@aocenas New PR from my personal fork. Go to town! 😄

What this PR does / why we need it:

Use cases are outlined in #40720.

This PR is doing a lot, so here's a roadmap to explain at a high level what types of changes you are looking at within each grouping of files. I'm also adding some comments in code to assist in navigating.

• packages/grafana-data/src/types/... Adds the concept of ExplorePanelsState, which allows us to encode the state of explore view panels into the url.
  • This is needed to enable deep linking to a particular datasource & query with the data visualization in a particular state (in this case - with a spanId focused).
  • The data structure maps preferred visualization type to a config object that would be specific to that visualization. This should be extensible for other use cases where you want explore pane visualzations to be configurable & deep linkable, such as @gabor's graph type use case (PR)
• packages/grafana-data/src/utils/... Serializes ExplorePanelsState into explore url and adds it to internal links.
• public/app/core/utils/explore.ts Deserializes ExplorePanelsState from explore url
• packages/jaeger-ui-components/... The UI work to add "focused span" behavior to the trace viewer. Adds the concept of focusedSpanId to the trace viewer components, scrolls the focused span into view and highlights it with a blue background. Knows nothing about URL, explore pane state, etc. Adds the concept of createFocusSpanLink, a function that takes a traceId & spanId and returns a LinkModel representing a deep link to the trace & span.
• public/app/features/explore/state/... Wire up ExplorePanelsState to redux, keeps it in sync with the url, wires it up to SplitOpen.
• public/app/features/explore/... Glues together ExplorePanelsState from redux to the Explore UI to the focusedSpanId and createFocusSpanLink features of the trace viewer.

[connorlindsey]

LGTM

[aocenas]

Looks good but can we add tests to see if the panel state is actually handled correctly? Seems like we always just pass {}. Also, there are some new functions that probably can be easily tested separately. @connorlindsey can you take that on?