Fix wait periods for MCUs with tick period > 1ms

[kindlehl]

This was a nice little example for me to jump off of. I just noticed that my LCD started spewing garbled text or wouldn't display anything after I commented out all of the ESP_LOGI calls. It turns out that the time that the ESP was spending writing logs over serial was enough delay to allow the LCD to finish executing its commands. Without that serial write period, it was going to fast and leaving the LCD in a bad state. On my board, pdMS_TO_TICKS(1) returns 0, so I was not getting any wait time.

This function isn't perfect. It doesn't actually match the lcd cycles, but it should give a reasonable delay. I've tested it with all the serial stuff commented out and it handles double-clears and long writes just fine.

Added function wait_lcd_cycles() to replace vTaskDelay with pdMS_TO_TICKS()

pdMS_TO_TICKS(ms) returns 0 when ms < tick period. If the tick period is 2 seconds, vTaskDelay gets 0, which invokes the scheduler and gives another task the chance to run. If there is no other task, the calling task just gets rescheduled immediately. This is not a long enough delay and leads to inconsistent behavior and garbled text most often on my LCD.

wait_lcd_cycles() should be used as it makes the task wait without invoking the scheduler. It should only be used for brief pauses in execution for a few microseconds.

[kindlehl]

with the wait inside i2c_transmit_with_enable_toggle, this wait is not really doing anything.

[kindlehl]

upon further debugging and deeper reading of datasheets, I think this is a skill issue on my part. I believe my real problem was a classic multitasking issue where there was a race condition causing two tasks to try writing to the i2c bus and clobbering the other's data.