Better handle peripheral device exceptions

[tomcur]

It is expected of peripheral devices that they sometimes behave unpredictably. For example, hardware issues (loose connectors, timing issues) can cause problems with communication. This can lead to a variety of exceptions.

Currently, any such exception stops the program, even though other peripherals might still be working as expected. This can be troublesome especially for kits that are controlling actuators such as lights or climate control, as the control process also stops.

There are multiple ways to implement handling of such exceptions. For example:

1. the program could indiscriminately catch any Exception (which does not include e.g. KeyboardInterrupt and SystemExit); or
2. a PeripheralDeviceException could be created, with peripheral device code being required to catch exceptions to rethrow as PeripheralDeviceException.

The first alternative works in most cases, but has the con of potentially catching too many exceptions (but which would we not want to catch?). The second alternative is likely to sometimes still fail for some unforeseen exceptions.

Once an exception has been caught for a peripheral device, for now we might simply ignore that device. In the future, an attempt at recovering the device might be implemented.

[tomcur]

Note that even though the program currently stops on exceptions, when using the official distributed kit images, the program is automatically restarted by systemd. However, due to #4, on some configurations the program can only be restarted so many times on a single boot before system resources run out.