Crazyflie-firmware: Revisiting startup and connection procedure

[evoggy]

We've had some issues with the start up and connection procedure that's created some questions we need to answer and to possibly rethink how the startup is handled and when we are connected. This was triggered by discussions around the PR bitcraze/crazyflie-firmware#1028 where we still have an issue of waiting for the decks to be initialized because we do not want to give access to the memory sub system before drivers are initialized. This is also connected to issue bitcraze/crazyflie-firmware#1029.

There's a few questions we should discuss:

• How to handle the start of a Crazyflie where one or more of the self tests fail. What tasks wait for what to start?
• When are we considered connected and how do we separate this from being connected to a Crazyflie where the test do or do not pass
• How do we handle nRF51<>STM32 communication when coming up from an assert while the nRF51 is still pushing data

There's probably more cases here, but this is mostly a placeholder and a discussion point to remember that we need to look into this.