TWI slave receiver releases SCL and returns to ready state prematurely

Commit 48bcef5a15f1b17aee877bdb8cf77c6b45faaa6e appears to have been an attempt to fix issue arduino/Arduino#1477. Contrary to what that issue says that problem was not exclusive to when two Arduinos are connected and the I2C slave Arduino was running at 8MHz; any slow device that stretched the I2C clock would hit the issue because the TWI master was not honoring an I2C clock stretch condition. That commit "fixed" the issue by having the slave receiver incorrectly release the bus before it was ready receive more data.

While the fix worked around a specific, exotic condition, it generally broke the case of Arduino ATmega328P as an I2C slave device on a fast-mode I2C bus (where responding to almost any request in a single clock cycle would be difficult) and did not solve the underlying problem in the issue which was that the TWI master did not honor clock stretching by slave devices (at the time; this may since have been fixed).

This is affecting a case where I'm using an Arduino ATmega328P as an SMC for a 6502 computer. The ATmega328P misses a portion of the I2C transaction because it does not stretch SCL and cannot process the last I2C byte and prepare a response before the next clock arrives. Using another 16MHz 8-bit AVR microcontroller (ATTINY861) does not exhibit this condition, even when the I2C handler's service time is substantially increased, because the Wire library implementation for that hardware does not release SCL prior to the service routine finishing.

Start by examining commit 48bcef5a15f1b17aee877bdb8cf77c6b45faaa6e and the AVR Wire library's TWI slave receiver implementation for ATmega328P. Compare its SCL handling with the ATTINY861 Wire implementation described in the issue; done means a fast-mode slave transaction does not miss the final byte or release SCL before the service routine is ready.

Written by the indexing model from the issue text.