feat: Add a preview to the data transformation interface.

[parkerziegler]

In addition to making console.log statements visible (see #26), we can enhance the visibility of data transformation programs by rendering a live preview of the transformation on the currently selected feature. This is inspired by live programming environments that eagerly evaluate user code and show the result as the user edits the program. Additionally, GIS interfaces like QGIS already do this in interfaces like the Attribute Editor. In our need-finding study, we saw that users (1) experiment with data transformation code by running a candidate operation and inspecting the output and (2) use only a subset of features to test an operation to speed up the feedback loop.

Because we'd only be running the transformation on a single feature in the dataset, this approach is likely to stay performant even with arbitrarily large datasets. Moreover, the result is not important to persist; we can easily discard results as users continue to refine their program.

An implementation of this feature would include:

• Adding a pane to the data transformation interface to show the output feature.
  • We should do some exploration down the line to determine if seeing both the input and output is useful, or if it's only important to show the output.
• Evaluating user code in a separate preview Web Worker and passing the output back to the main thread. Evaluation of user code should be debounced.
• Presenting errors to the user. Errors should be raised explicitly with no output returned in the preview pane.
• Presenting warnings to the user. Warnings should be raised when the returned data is not a GeoJSON Feature, but we should still return the output of the code.
  • Longer term, we may want to use geojson-validation or geojsonhint to perform the validation for us, but it's not worth the bundle hit just yet.