Fix issues observed in continuous mode

[claws]

Continuous mode examples were not working properly. Now both Continuous and One-Time mode examples work as expected. Values are observed without problems being reported (i.e. first measurement appears to work fine). This change should resolve the problem noted in #28.

This change fixes #27, #28.

Other changes:

• Adds a boolean variable to track whether the device has been configured. This can be used to abort readings if necessary.
• Fixes for various spelling errors.
• Update the advanced example with a demonstration of using the return value from begin to detect setup problems.
• Updates consistency of some error messages printed out when debug is enabled.

[coelner]

1. The Problem is gone, but not solved at all. You push the continuous mode to the behavior of one time mode. The continuous mode has the advantage that you don't need to wait for a measurement, because the sensor did it already for you. currently there is no difference between continuous mode and one time mode.
2. the boolean is not needed. You could predefine the private uint8_t BH1750_MODEwith the value 0x00 and check this, because it get only written if the configure() call was successful. And this variable is misleading, because we can't read this value from the sensor over i2c, we assume it only internally. Maybe the sensor is hitted by a power reset and return without our knowledge unconfigured.
3. the different modes could be part of an enum structure (e.g.: https://github.com/finitespace/BME280/blob/master/src/BME280.h)

[claws]

I'm attempting to fix these issues in #33.