This destructor allows reassigning either hardware peripheral to the default Wire() objects.
sequence:
Wire.~TwoWire();
Wire = TwoWire(peripherial); // peripheral is either 0 or 1
Wire.begin(sda,scl); // sda, scl are the pins to use, when using peripheral 1, YOU MUST specifiy the pins, there ARE NO DEFAULT VALUES for peripheral 1.

These changes allow both i2c peripherals to be use, if a TwoWire() object is destroyed, the associated peripheral is reset and powered down.

This change will not reset the SCL, SDA and Frequency values to their default value if `Wire.begin()` is call without any parameters.  Arduino libraries that use `Wire()` usually have a call to `Wire.begin()` inside their initialization call.  Without this change, any custom pin assignments are lost whenever `Wire.begin()` is called.

Changed how default parameters are interpreted.  Now calling `Wire.begin()` without parameters will reuse the current values instead of resetting them to the default values.  This change was prompted when it was found than custom pin assignments were being lost.  The standard Arduino library practice is to issue a `Wire.begin()` call inside each library that uses `Wire()`.  If a custom pin assignment was used, when these libraries were init'd, they caused a failure when they re-assigned the SDA and SCL pins.  Changing Frequency back to 100khz was not a fatal problem.

Create Destructor for Wire Class. Preserve Custom SCL, SDA across `Wire.begin()` default calls.

Time out recover was generating a confusing error message when DEBUG level was set, Clarify meaning.  Thanks to @valki2

When Arduino 1.8.5 configured for maximum compiler warning, my sloppy code generates multiple errors. :grimace:  Thanks @PicoEmma
I fixed most of the warnings, but I haven't figure out how to clear one type of them.  I use a structure to decode a peripheral memory register, the compiler reports it as an:
>
C:\Users\e\Documents\Arduino\hardware\espressif\esp32\cores\esp32\esp32-hal-i2c.c: In function 'dumpCmdQueue':
C:\Users\e\Documents\Arduino\hardware\espressif\esp32\cores\esp32\esp32-hal-i2c.c:399:17: warning: variable 'c' set but not used [-Wunused-but-set-variable]
   I2C_COMMAND_t c;
                 ^

Chuck.

esp-hal-i2c.c: 
* fix timeout debug message @valki2
* fix compiler warnings @PicoEmma
* add debug level display

Did a direct file edit, and of course I failed.

xEventGroupclearBits() does not return an error code, just the prior values of the flags.

If Core Debug Level is at DEBUG, a confusing debug message will be emitted if the I2C transaction takes longer complete than the calculated minimum time. This original debug message was just to prove that this new i2c code could correctly handle SCL stretching or interrupt latency issues. This delay is not a problem, or an error. Usually it is caused by a higher priory interrupt starving the i2c ISR. Usually WiFi is the culprit. As long of this delay is within the configured timeout (by default 50ms, or can be set with Wire.setTimeOut(milliseconds);) no problem will occur and the transaction will successfully complete.
Chuck.