Improve message search UX

[rikimaru0345]

Some things from #48 didn't make it into #54

Helper functions (Important!)

What if the user wants to search for one specific property in a deeply nested object?
There should be a function that takes the name of a property (or partial path!), like:
findProp("player.score") to return the value of the first matching property.
Also: findPropAll("...") to return an array of all matches.

UX Improvements

1. Filter Settings
   The filter "tags" (or "pills") are currently not somewhat awkward to use since they can be clicked once to toggle them on/off, and double-clicked to open their properties.
   The double-click functionality should probably be replaced a gear icon on the left side.
   That way a filter entry would have 3 clickable regions: Settings - On/Off Toggle - Delete

2. JS Examples
   The examples section is currently just a placeholder...

Expression Editor

In order to be able to provide an expression editor (with dropdowns for existing properties like in kibana), the frontend needs a list of all the properties.

This will probably take a while because it pretty much requires the "schema detection" feature, which in turn most likely requires a database...

Bytes (Later)

Eventually we probably want to be able to work with the raw message as well (so provide something like a Buffer(?) from nodejs so the user can access the bytes)

[rikimaru0345]

• for 1.1 we won't be able to add the expression editor since it requires some significant backend work.
• "byte access" is not important enough right now either.

however for 1.1 the remaining points are pretty important:

1. helper functions (findProp, findPropAll, and more, if we can think of any more interesting/convincing use-cases)
2. "filter settings ux": double-click on a filter is the main issue, that needs to go! Turning the a filter button from a 2-part [ FilterName | CloseX ] thing into a 3-part thing [ Settings Gear Icon | FilterName | CloseX ] is probably the best solution here.
3. The "info" bar at the bottom of the JS dialog is still a placeholder. We definitely need more basic info, as well as some good examples there that cover common use cases...

[rikimaru0345]

It is entirely possible to just add the helper functions to the frontend (adding/injecting) them into the code that "compiles" the filters to "JS source code",
its not a clean solution however. The helper functions never change, so they should be part of the "js environment" in the backend and stored there. (No point in sending them over the wire every time a search is done that uses a filter...)

For debugging/testing they can of course be added to the frontend. (I wouldn't even mind to release 1.1 like that! As long as we eventually move them to the backend...)