Refactor channels and reducers

[egervari]

Removed Reducers, Scanner, ScannerChannels

Reworked Channels to be simple and assembly

Reworked AuguryBridgeMessage type to accommodate different payload types. Clarified augury bridge message/request types

Added ProbeChannel and AssemblyChannel and reworked Channels in general

Now tracking completion date in Probe class and removed markComplete() - there's no reason to delay this any longer due to the removal of reactions/enhancers - there's nothing to wait for anymore.

Removed ProbeConstructor type and ability to get probes via constructor - it's no longer needed

Added Projection interfaces and EventDragInfo Projection

Rewrote all existing channel and reducer functionality using projections and assemblers. Added types for all outputs on projections/assemblers. Updated plugins and execution timeline angular app to use new augury bridge types and segment types

Performance has improved immeasurably from removing the Scanner.

[andrewthauer]

@egervari - One quick thing I noticed. Looks like the "Show Augury Drag" check box might not be working right anymore. Seems to clear out the other bars when you check it. Should be an overlay on top of the others.

[andrewthauer]

I really like the direction this has taken overall. It seems to simplify and remove concepts that are not necessarily required to facilitate the overall objective of the tooling.

I do have some additional thoughts we could discuss in more detail (which can tentatively be handled in subsequent efforts). For documentation purposes here they are at a high level:

Core

• Consider merging the assembler & projection concepts into a single concern "projection" (which handles both). Seems the projection one is only used once so it's more likely the assembler concept is more common (although I like the name projection better). This would allow for a single channel type thus simplifying the API. Some possible interfaces:

// possible interface
applyEvent(input: Input): { done: boolean };
getValue(): Output;

// or something like this
next(input: Input): { data: Output: done: boolean }

Plugins

This is not new, but the plugins in general are really capturing at least 2 distinct concerns (probably more). On one side they are acting like middleware consumers of the event stream. The other thing is they deal with window objects.

• Can we de-couple the concept of the controller/window from pure data collection?
• Doesn't feel like window type stuff should be in core
• Split up bridge from plugins (organizationally)