Expose the debugger index with a nice API

[jpmonettas]

Quoting Carlo on slack :

I can see a way of using the trace information in a lot contexts in the development flow. On the top of my head:

    1. Synthesizing all the spec information for parameters that flow into a function (using something like https://github.com/stathissideris/spec-provider on the aggregation of multiple annotated traces. Also, retrospective type anomaly detection.
    2. Keeping a record of traces, document how the codebase changes with time. We could have a set of root expressions in our test suite, with a record of how they behave obtained with flow-storm. After a change, or maybe at PR review time, we could diff the executions to understand what kind of flows are impacted by the change. We could use this internally as a process tool to simplify the discussion of a PR review.
    3. Predicate-based filtering of arguments. Like, show me all the places in this execution in which the parameters, as an aggregate, satisfy this predicate. This is somewhat possible with conditional tracing, but if you have the traces you can do every possible manipulation post-factum, which improves the feedback loop.
    4. Visualization lenses over traces: say I have a loop-recur process in which I am computing new versions of an accumulated data structure, but I want to see only some derived data instead of the entire data-structure (like, a visualization based on every frame of the loop).
    5. Bifurcation point analysis: In this trace, what are all the choices that I made? (every if, cond etc). Can I display that in a graph? Can I find automatically other traces in my trace db that explore other bifurcation choices? Can I be sure that my test suite is covering all the bifurcation possibilities?

These are only some examples, I really think that the power in this kind of approach lies in giving the programmer the means to directly iterate on this kind of ideas, via an API (which in an ideal world would just be the traces as data).