Removed second delay on eeprom writes

[David-OConnor]

This PR removes the second delay during EEPROM writes. This delay is due to the note in the datasheet that a delay of 5ms (conservatively 10ms) between eeprom writes is required to prevent bugs. I've confirmed this: Wacky stuff happens if you don't delay!

This PR is due to the delay being inconsistent: We need the one between the writes. Currently, the onus is on the user to execute delays otherwise, ie between reads, or between read and write commands. I see two options:

#1: This PR as-is, ie removing all internal delays except the one between two writes. The user must insert delays etc in their code.
#2: Add a delay after or before each read. This would avoid the user having to add delays, but adds latency in situations where it may not be needed

[eldruin]

The delay is necessary after EEPROM writes, not before or after EEPROM or RAM reads. So I think the current state is correct.
Did I miss something else?

[David-OConnor]

Anecdotally, if I don't insert manual delays between reads, or reads and writes, the device behaves unpredictably, eg crashes, setting the wrong value etc. So, I've been treating it as required between all operations. Could this be because the read process involves writing the address?

For example, this works:

    let mut temp = sensor.object1_temperature().unwrap();
    delay.delay_ms(10);
    let emis = sensor.emissivity().unwrap();

But this doesn't:

    let mut temp = sensor.object1_temperature().unwrap();
    let emis = sensor.emissivity().unwrap();

I chose this approach in the PR instead of adding delays before or after each read, since perhaps you won't want the delay if you're using a wfi between readings anyway.

[eldruin]

I have removed the delay as suggested here, thanks!
I have also implemented support for device sleep/wake and released everything in version 0.2.0.
Closing.

[David-OConnor]

Sweet