Eliminate old implementation of seeking

**Describe the bug**
There are a few remaining uses of AudioIO::SeekStream, called by the main thread, with the intent of sending a message to other threads, to reposition playback in progress, in response to some input event from the user:

* Fast-forward and rewind buttons of effect preview
* Several Select menu items, with certain default key bindings
* Cursor Short Jump Left / Right -- , and .
* Cursor Long Jump Left / Right -- Shift+, and Shift+.
* Cursor Left / Right -- left/right arrow keys
* Short Seek Left/Right During Playback -- left/right arrow keys (to do: understand how command manager overloads these keys)
* Long Seek Left/Right During Playback -- Shift+left and Shift+right
* Selection Extend Left/Right -- Shift+left and Shift+right

The message is sent by setting a variable (AudioIOCallback::mSeek) that isn't properly atomic .

Then the response is implemented in the low-latency thread with a mutex lock (!), discarding of the contents of the ring buffers, sending a message to the TrackBufferExchange thread to prime the buffers again, and then resumption.

Obviously this creates a stall in playback.

Other methods of sending information to the threads have been developed in the years since this was written, such as responding to adjustments of looping play boundaries, where the response is handled on the producer side of the ring buffer, not the low-latency consumer side.

The vestiges of the old seeking should be eliminated in favor of these newer methods.