Reduce or eliminate use of `delay()` in `IMU.init()` calls (LSM6DSL)

[quicksketch]

Hi @LiquidCGS, thanks for making this library. It's been a big help making my IMU code work across multiple devices.

I'm currently using a LSM6DSL IMU and I'm encountering two issues with it:

1. I'm initialize the IMU very quickly after booting, and apparently sometimes the device isn't ready yet. The call to readByte(IMUAddress, LSM6DSL_WHO_AM_I) returns nothing. I can fix this problem by adding a delay(500) before calling LSM6DSL::init(). However, this is undesirable since I want a very fast boot time.

2. When the device does init successfully, LSM6DSL::init() contains its own delay(100) that adds unnecessary waiting and delay. According to the LSM6DSL specifications (page 49), a soft boot call only should take 50 nanoseconds:

The SW_RESET procedure can take 50 μs; the status of reset is signaled by the status of the SW_RESET bit of the CTRL3_C register

What I would like to propose to hopefully solve both problems is that a while() loop be introduced to check if the device is ready, rather than either assuming the device is already ready when init() is called, and then check if the device is ready after executing a soft reset, rather than hard-coding a delay. I'll see about filing a PR.

[quicksketch]

I filed a PR at #27 that seems to help both the problems described.

Using the following sample code to test:

  LSM6DSL IMU;
  calData calibration_data = { 0 };

  // Initialize IMU.
  Serial.println("Initializing IMU.");
  unsigned int imuStartTime = millis();
  int err = IMU.init(calibration_data, IMU_ADDRESS);
  if (err != 0) {
    Serial.printf("Error initializing IMU: %d\n", err);
  }
  Serial.printf("IMU initialized in %dms", millis() - imuStartTime);

I was previously getting -1 errors about 50% of the time, and the initialization timer was 100 or 101ms. After this change, initialization is working 100% of the time, and the initialization timer is 1 to 2ms.

[quicksketch]

I'm sorry @LiquidCGS, my PR caused a regression. Looking at the compiling log closely, I get a warning caused by trying to pass too large a value (500) into a uint8_t (which caps at 254). I filed a follow-up PR to lower that value at #41

[LiquidCGS]

I'm sorry @LiquidCGS, my PR caused a regression. Looking at the compiling log closely, I get a warning caused by trying to pass too large a value (500) into a uint8_t (which caps at 254). I filed a follow-up PR to lower that value at #41

Hey, no worries! I'm a tad busy at the moment I'll check this out properly later during the week or maybe during the weekend