more precise telemetry types

[mbostock]

This removes the [key: string]: unknown in TelemetryData that was not being explicit about the contents of telemetry events. Furthermore, this adopts an explicit enumeration of event + step as a union type, such that any additional fields of telemetry data are tied to specific events. And this adopts a page loader so that we don’t have to remember to copy-paste the code into the documentation if and when the types change.

This raised a few questions:

• Should we have a build + error event to report build failures?
• Should the deploy + buldManifest event have a step, or be folded into the deploy + finish step?
• Should the signal event be associated with the current command (one of {build, deploy, preview, login})?

[visnup]

This reminded me why I annotated these as test: true: in case these events ran in CI and made it into our production events, I wanted an easy way to filter them out. Unsure if that's a good enough reason to keep it this way or not or simply try to firewall off any chance of them showing up in our actual data.

I did just double check and we have no recorded events with test: true in them.

[visnup]

The signal events can come at any time, outside of a known workflow since they're from system callbacks. So, in order to track it correctly, we'd need to set some global state somewhere for that callback to be able to reference.

[visnup]

I would expect errors to be the top-level event type. Oh, and we do always have session ids to correlate what was happening before something like an error or signal occur, within the same session.