Add new method to Wire library

It seems necessary to add a new method to the Wire library to avoid buffer limitation.
We could create a method which pass directly a buffer of data to send directly to the i2c core without to use the write() method several time:
uint8_t write(uint8_t *buffer, uint16_t size); shouldn't call write(data[i]) but save and pass the pointer to endTransmission().

[LMESTM]

This would definitely improve performances - possibly significantly

Same issue for requestFrom(). We could add a method to pass a buffer from the user layer and not use the internal rxBuffer[].

[bperrybap]

I doub't it will add much, if any, i/o performance given that Wire runs as 100Khz by default.
At the higher speeds like at 1M, there might be some gain, but even then it would likely only benefit larger transfers like when using an EEPROM/NVRAM.
I think before anything like this were added to the API, that it should be prototyped and actually measured with a logic analyzer to see just what benefits, if any, you actually get.

Now from a functional perspective, if the new functions could handle arbitrary transfer sizes by doing multiple smaller sized blocks to fully send/receive larger blocks of data on behalf of the application, that would be a very beneficial feature.
i.e. you could read/write large blocks of data to an EEPROM vs having to do all the fragmentation into 32 byte requests up in the application.

In fact, increase performance is not the goal of this issue.

The goal of this issue is to avoid a problem of memory usage. A size of 32 bytes in the internal buffer (inside the library) is enough for most of applications but sometime you need to exchange more than 32 bytes in one time. So to not increase the memory usage (when not needed), a new method is added to use a buffer with a size known by the application.

The STM32 HAL is able to manage a large number of bytes but not the Wire library without the patch #131

[fpistm]

Currently, I've an issue with an I2C eeprom with this patch on lower address. I'm searching why.