Fix MSD flashing for kl26z (microbit)

[mathias-arm]

I bisected to find out when kl26z_microbit_if MSD flashing stopped working (DAPLink crashes). This led me to [f1bb93e]. The attached heavy-handed change fixes for gcc and armcc.

@gerargz, @flit, @carlosperate: other nRF51822 platforms seem to work without this patch, but I am not sure why why it only impacts kl26z.

[microbit-carlos]

@gerargz do you have a bit more info about why this addition was required?

[flit]

Do you know why DAPLink crashes with this code in place? What are the fault syndrome register values, and which instruction faulted? Could it be a stack overflow?

If you're getting an imprecise fault, you can add this code to init to force precise faults (at small performance penalty):

    // Disable write buffer to make bus faults precise.
    SCnSCB->ACTLR = SCnSCB_ACTLR_DISDEFWBUF_Msk;

(Frankly, it's bad that DAPLink wasn't powering down debug after MSD programming all along.)

[flit]

@microbit-carlos Powering down debug after programming will reduce power consumption of the target.

[mathias-arm]

This issue might be relevant: microbit-foundation#9

[mathias-arm]

I checked with micro:bit board and the problem is that the first call to read DP_CTRL_STAT fails. With the assumption that after a reset the target is not ready for SWD, I have added a call to swd_init_debug() and it seems to fix the issue. It is probably does a few superfluous operations, but I think it is cleaner.

[mathias-arm]

I also changed the checks mentioned in microbit-foundation#9