After #111 & #114 we decided to change the way expander are handled in startups.

What is to change:

• after initiating an expander module, stop the normal execution of the startup script or the console with a while loop, until the expander is ready or a timeout is surpassed.
• execute the startup script "normally" (most expander/proxy functionality won't be set up correctly)
• make it possible to flash an expander esp in the error state
• let the error state be broadcasted → core.has_error can be subscribed with broadcast

Error handling, example implementation for expander module:

• error code functionality
• set errors
• have an error status readable → core.has_error is a bool property, that can be subscribed with broadcast
• have a way to receive all errors → core.get_errors()

Ideas for future additions:

• if a proxy is created while the expander module is not ready, there should be an error
• don't let critical functions execute when in the error state
• Handle different error states → ideas: No Error, Connection Timeout, Connection Failed
• Notify the user about the error state → other than broadcast, maybe when using Lizard
• important modules have their own error states → Core, Expander?
• when meeting the initial timeout, try to reboot the expander esp until it is finally in an error state