Decouple Tape Browser updates from emulation pause

[morozov]

Problems solved

1. Audible gaps between consecutive blocks that use short pilot tones. For example, some releases by DiggerSoft have turbo blocks with pilot_length = 1084 T and a pulse count of mostly 16. That comes to about 5 ms total, and the blocks are meant to play as a single whole.
2. Opening the Tape Browser pauses the emulator for a moment. Noticeable with any tape, and may break loading with some loaders.
3. The Tape Browser viewport doesn't scroll to follow the highlighted current block as playback advances. This is noticeable with tape images that have a large number of short blocks.

What this PR does

Removes both pause wraps from the Cocoa Tape Browser — the one inside ui_tape_browser_update and the one around TapeBrowserController.showWindow:. The browser's UI updates already dispatch asynchronously to the main thread, so neither wrap is load-bearing on Cocoa; they're vestiges of the original GTK1 single-threaded design. The previously-synchronous cross-thread setDocumentEdited: call becomes a setDocumentEditedFlag: main-thread dispatch so the function is thread-correct end-to-end, and the NEW_TAPE walk (the only branch that iterates tape->blocks directly) is dispatched onto the emulator thread via performSelector:onThread: — the same thread where save-trap and RZX block appends fire — so list iteration and mutation are serialised on a single thread.

setTapeIndex: now calls -scrollRowToVisible: after -setSelectionIndex: so the highlighted current block stays visible as playback advances.