Status and SystemIO class, refactoring and fixes

Defect fixes:

    DeviceManager::getDeviceByType() returned the first registered device even if it was not active. The result: I had the DMOC de-activated and the Brusa controller activated but got the DMOC returned by the function. This might have been the cause for the problems of Mark and Jack.
    The ichip device uses buffered output (cool idea btw !). The amount of commands sent during loadParameters() caused a buffer overflow and some comands/parameters were not sent to the chip. I increased the buffer size, seems to work fine now.
    The send buffer was not delivering its full potential. I changed the code so that after every line, the device frees the main loop() and gives other devices the chance to process stuff (and e.g. not cause a CAN message timeout in the motor controller). So in essence, processing the content of the send buffer is non-blocking now.
    Disabled the instanciation of the elm327 device as it caused dead-locks.
    Initialize the variable paramCache.timeRunning = 0; in ichip_2128.cpp as the variable was apparently not zeroed at system startup and thus the timeRunning never got updated

Enhancements:

    sys_io is now a class -> SystemIO and allows to set the state of logical outputs (pre-charge relay, brake light, etc.). Hence you don't need to know the port number outside of the class anymore.
    Added Status class which can be used to track various status flags and the system state and to forward this data to the website. Make sure in your motor controller code to set the variables of the Status class where possible (e.g. for overtemp, undervoltage, etc. - depending on what the CAN messages of the controller report). The bitfields are now calculated by the status class for use in the website. Direct anipulation of the bitfields outside the class is no longer possible (as it was hard to maintain it that way).
    There are still some reserve bits in the bitfields of Status for future use. (see Status.cpp)
    Eliminated all getInstance() calls in critical areas. As a consequence e.g. all classes derived from Device share variables for  Status, DeviceManager, TickHandler and SystemIO
    The extended lights in the annunciator panel are no longer Brusa specific - although still inspired by it. I think we should keep them and amend them when new controllers report more. The amount of flags should not be the smalles common but the union of all. I'm sure it's also possible to control some more lights from the DMOC controller. Just use the Status class and set its fields. (refer to BrusaMotorController.cpp to get inspired).
    The OUTPUT 0-7 lights are automatically maintained by SystemIO. I also added INPUT 0-3 lights which are also automatically handled.
    Because of Status::get/setSystemState(), there's no need anymore to have the fields "ready", "running", "error" in the MotorControllers. Only Status::warning is kept as it might be enabled in any possible system state. I integrated it into the DMOC controller but didn't dare to touch the controller's class own state engine.
    In ichip someone introduced temporary string buffers to output data through the Logger. This is not necessary, as the same can be achieved by Logger::debug(ICHIP_WIFI, "this is a sample message: %s", msg->c_out());
    Removed the definition CFG_TIMER_USE_QUEUING as timer queueing seems to work stable now (was the default setting anyway)
    Added and renamed some config parameters in the serial console. If they are not exlained well enough, please tell me. I also volunteer to adjust the manual accordingly. (e.g. COOLFAN is now COOLRELAY as it doesn't necessarely have to be a fan but could also be a pump or an actuator that could be controlled by this)
    I still introduced the pre-charge, HV- and HV+ control in the pre-charge sequence. With configuration you can pursue all three pre-charge approaches:
        Pre-charge and Main-Contactor, leave pre-charge on: use "HV Negative" to control the pre-charge relay - it will stay on.
        Pre-charge and Main-Contactor, switch pre-charge off: use "Pre-Charge" to control the pre-charge relay - it will turn off after the pre-charge cycle
        Three contactor approach with HV Negative, Pre-Charge, HV Positive: use all three outputs
    I also added the possibility to assign the "enable" input signal to a digital input port. Also there is a new "enable out" signal. If configured (!= 255), the specified port will be enabled at the end of the pre-charge cycle. It can be used to signal the controller to go to "ready" mode.