Separate out the SEGGER RTT\0\0\0 header from the rtt block

[thejpster]

There is a small risk that the probe will inspect RAM whilst we are in the middle of copying from Flash to RAM, and it might see the SEGGER RTT header but then see invalid pointers.

So we should initialise with the header set to something other than SEGGER RTT and paint in those few bytes manually after the fact.

But also we should probably wait for probe-rs/probe-rs#1722 to land because making the RTT block valid later on in the boot cycle will increase the chance of it failing to find the block on the first pass.

[thejpster]

See https://github.com/probe-rs/rtt-target/blob/47076554ff5bde879a3e0562b27b93c06bfa18d0/rtt-target/src/init.rs#L147-L162

[bugadani]

There is a small risk that the probe will inspect RAM whilst we are in the middle of copying from Flash to RAM

Interestingly, with certain ESP32 MCUs this is hit pretty often, causing probe-rs to print errors. Additionally, if defmt is used in firmware that is running from RAM, probe-rs may incorrectly detect the wrong magic string as the control block, completely breaking RTT.

For maximum compatibility, I'd suggest making sure the magic string is not present verbatim in the binary, and that it is written to the control block last. The official implementation contains the string backwards, for example.