Seeking very slow

[joshbarrass]

At the moment, seeking is very slow. This is somewhat to be expected, as seeking is performed by running the emulator as fast as possible and binning any sound data that isn't needed. However, it feels a lot slower than I would expect it to be. I expect a lot of this is because the emulator only generates ~1000 (I think it should be 960 on average, but would have to double check) samples at a time when run for 250,000 cycles, so we spend a lot of time incrementing various counters and resetting the buffer to empty. It would be better to either:

1. Run the emulator several times (either at the current 250,000 samples, or a larger value if it is shown to improve performance -- maybe this could be an argument to the seeking function) until the buffer either a) reaches some arbitrary size, or b) we hit the sample we were seeking for (or, in theory, both; the buffer will continue to hold the data and subsequent read requests will just pull from the already buffered data). Then we a) empty the buffer, or b) empty up to the sample we want.
2. Scale the number of cycles we run the emulator for based on the number of samples we need to skip. This way, we can jump to approximately the right location straight away and do more fine-grained adjustment afterwards.

Option 1 is probably going to be the slowest, but will give much more control over the memory usage of the plugin. Option 2 would be the fastest as it should involve very little logic in the plugin itself, but the buffer will likely grow quite large as it needs to accommodate most of the track. Vectors are being used under the hood, so this isn't a big deal as the buffer can grow as it needs, but the buffer's size is never reduced at present (the buffer is actually, at the time of this edit, being resized at the start of every write). On most PCs, this will probably never be an issue, but it seems a bit pointless to hold open a very large buffer for no reason; I'd want to add in some way of automatically reducing the buffer size again.

Finally, both options could actually be implemented, with some logic at the start that decides which option is going to be the best. If we aren't seeking by many samples, then we could use option 2 quite happily without needing a huge buffer, but if we're seeking e.g. from the start of a several minute track to the end, we could use option 1 to keep the buffer size low.

I recommend not attempting to solve this issue until #11 has been implemented.

[joshbarrass]

Some preliminary experimentation with option 2 had very little effect on the speed of seeking. It may just be that seeking is slow, and there isn't much that can be done; however, there could still be other things at play here; perhaps the operations being performed on the vector are slow?

[joshbarrass]

This is seemingly worsened by #25, though I'm not sure why as this PR should not modify the seeking function.