Allow lz_highlight_match to trigger filtering instead of display

[abought]

Purpose

There exists a mechanism to update the plot and change how elements are displayed. "If gene name matches a field on the arc track, then draw the arc as a red line".

Now that we have a feature to filter ("do not render") elements, it is worth considering whether this could work with the existing "display only" match feature. Can matching trigger a new filter behavior?

A sample syntax might be to replace receive ("check a match on field value") with receive_filters, to trigger different behavior:

{send: 'x', receive_filters: []}

"When a match event is broadcast to the plot, apply a set of filters to the data before rendering".

@Parul-Kudtarkar , any thoughts on sample use cases?

[abought]

Another sample use case from discussions with the Broad:

"Connect scatter plot to interval tracks: select a scatter point, and annotate all regions/intervals that overlap this variant. Eg, filter a rendered track based on elements selected on a different track."

This represents an extension of the lz_highlight_match functionality: a value should be broadcast from one panel, and received/acted upon by filters in another. Currently filters are static ("field value compared to a constant"), and match only handles exact match values.

[abought]

This will be addressed in #224: filters can now use lz_highlight_match (the internal "I matched something you clicked" indicator) as the field to filter on.

In practice, I tend to prefer that "match" events trigger a more subtle display rather than removing something from the plot (filter). This is because the workflow is "click to match, click again to clear"... if not implemented carefully, the act of matching would end up removing the element of the plot. Without a separate way to clear the filter, that would be awkward UX.