Offload transformations onto separate thread

[richiejp]

• sheet: Offload user transformations to background thread

Instead of doing the entire transformation in the foreground, this does an
initial chunk of the transformation in the foreground then offloads the rest
onto a background thread.

When new data is written to the transformation file the background thread
signals that new data is available and the UI buffer is reloaded.

The effect is that the user can see the transformation happen. If the index
were also built incrementally as new data became available then they could
start browsing the partially transformed file. This would require some work on
the index which currently just gets started after the transformation is finished.

As with doing the index in a background thread, this introduces a number of
problems. The background threads rely on UI buffer to store the mutex and other
resources, but the background threads are detached from the main thread and the
UI buffer is deleted on the main thread. So the background threads can outlive
the UI buffer. (fixed)

Probably the UI buffer should not own the mutex and threads should not be
created on an ad-hoc basis, but instead be part of a thread pool that executes
a work queue or some similar scheme. This is probably beyond the scope of this
PR, but worth noting.

TODO:

• fix bug which prevents the handler from being triggered and causes the status to disappear
• add a cancellation point into the transformation loop
• prevent UI buffer being free'd before the transformation has finished or been cancelled
• prevent actions (e.g. search, filter) from being carried out on the buffer while transformation is in progress
• convert filter to use the transformation API
• add destructors to free user supplied resources (or find way to use the current buffer destructor)
• fix failing extension test
• fix display error when opening a particular 2 column file results in a third column being added with data from the first and second column
• tests

[richiejp]

One thing that would be nice to add to this is that the index is built with the transformation. Another is that as the index is made available while it is only partially complete. Then the user could begin to browse more than just the first buffer's worth of the file. However it could require some more intrusive changes and this PR is already quite large. @liquidaty

[liquidaty]

One thing that would be nice to add to this is that the index is built with the transformation. Another is that as the index is made available while it is only partially complete. Then the user could begin to browse more than just the first buffer's worth of the file. However it could require some more intrusive changes and this PR is already quite large

Agreed, in particular the first-- will merge this PR and then can make that a separate new one