Revise preamble generation to fit frame-based architecture

[MustBeArt]

pluto_msk has support for generating a preamble when PTT is asserted. I'm talking about the mechanism hooked up to the Tx_Sync_Ctrl and Tx_Sync_Cnt registers.

The problem is, this implementation doesn't fit in with the frame-based design we're working with now. Or so I believe. It needs to bypass all the frame processing: frame sync word insertion, randomization, FEC, interleaving.

For current testing, we are generating the preamble in Dialogus. Because of the strict frame-based design we've converged on, this limits the preamble to a whole frame (40ms) or a multiple thereof. That's not ideal. If we are able to tune the receiver for great acquisition performance, we hope to be able to get by with a much shorter preamble. If we are able to do that, we'll need hardware support for transmitting a short preamble. Zero preamble won't work (I believe) because we need to reliably receive the first frame sync word and the first frame.

We'll also need to take a look at the timing when PTT is asserted. Right now, as described in msk_top_regs.md, the preamble is asserted after PTT is asserted, for a certain number of frames. If we can guarantee that the first frame is ready to go out to the modulator at that time, then good. If not, we need to change the definition. Either we redefine Tx_Sync_Cnt to define a minimum duration of the preamble, or else we need to hold off the start of the preamble until we know the timing of that first frame, so that we can transmit the minimum/nominal length preamble.

This change will need to be coordinated with matching changes in Dialogus.

[MustBeArt]

I just realized this is even more important than I previously thought.

Right now, with Dialogus doing all the frame "processing" (randomization, FEC, and interleaving, or placeholders for these), we have allowed Dialogus to generate the preamble at the beginning of a transmission. However, we don't have a mechanism to mark that preamble frame as special. Once we are able to move the "processing" into hardware, we will have to do something about that preamble frame, so that it doesn't get mangled by the hardware processing.

We could conceivably continue to generate the preamble in Dialogus, but then we'd have to add some ugly metadata either in the stream or parallel with it, so we could flag the preamble as not to be processed. That could be made to work, but I think it will be easier, cleaner, and more likely to work reliably if we just let the modem handle the entirely job of preamble generation.

The existing register definitions are approximately the right ones (though I described them incorrectly in the opening comment above). The preamble generation (which is described in the modem register documentation as "generation of transmitter synchronization patterns" or just "sync transmission") is triggered when the bit in the MSK_Control register identified as "PTT" (though it isn't really push-to-talk, but rather transmitter enable) changes from 0 to 1. This is the same logic Dialogus uses now: if we were not already transmitting, and we need to start transmitting, we generate a preamble. The preamble has a predetermined length (always one frame in Dialogus, or a number of bit times in the modem) and the very next bit transmitted must begin the frame sync word of the first payload frame (or be padded with more preamble).

I bet we currently generate a bogus frame sync word before the preamble. That would also go away if we let the modem handle preamble generation.