Added setRowOffsets to LiquidCrystal library

Original commit by Mark Sproul, but cleaned up by Matthijs Kooijman.
Make the LiquidCrystal row offsets uint8_t instead of int

Since these are memory addresses, there is no need to make them signed.
Furthermore, the HD44780 chip supports memory addresses up to 0x67, so
uint8_t shouldbe sufficient.
In LiquidCrystal::setCursor(), check against length of _row_offsets as well

Before, the row value was maximized against _numlines already, but the
value from _numlines is not limited anywhere, so it could be longer than
the length of _row_offsets. This check makes sure the array bounds is
never exceeded.
Support more LiquidCrystal displays out of the box

Previously, the row offsets were hardcoded to the ones used for 20x4
displays (which woudl also work for all 2-line displays). Now, the
number of columns given is used to calculate the offsets most likely to
apply.

For 2-line displays and 20x4 displays, the (used) offsets are completel
unchanged. With this change, common 16x4 displays and (if they even
exist) other 4-line and 3-line displays might also work (depending on
the hardware configuration used, of course).

See this page for some info on common LCD sizes and configurations
encountered in practice:

http://web.alfredstate.edu/weimandn/lcd/lcd_addressing/lcd_addressing_index.html
In LiquidCrystal::begin(), use a define instead of a hardcoded 0
In LiquidCrystal, remove an unused variable
Enable user to change the I2C clock frequency by calling setClock in the Wire library
fix comments on spaceship example

The comments explaining the if..else part were mistaken.
Merge pull request #2042 from jaimeiniesta/patch-1

fix comments on spaceship example
Modified Keyboard Reprogram example

Updated to reflect changes with how the IDE creates new blank sketches.
Fix comment typo
Remove unneeded register and ISR names in HardwareSerialx.cpp

Before, HardwareSerial1+.cpp were a copy of HardwareSerial1.cpp with all
0's replaced by the corresponding number. This would mean that e.g.
the Serial1 object would use the UBRRL register instead of UBRR1L when
it was defined, or the USART_RX_vect instead of USART1_RX_vect.

In practice, this would neve actually cause problems, since:
 - No avr chip currently has both the non-numbered registers as well as
   numbered registers.
 - HardwareSerial.h would only define HAVE_HWSERIALx when the
   corresponding numbered register is defined (except for
   HAVE_HWSERIAL0, which is also defined when the unnumbered registers
   are present).

Furthermore, before both the UARTx_xx_vect and USART_x_xx_vect was used.
Looking at the include files, only UART1_xx_vect is actually used (by
iom161.h), the others use USARTx_xx_vect. For this reason,
HardwareSerial1.cpp keeps the preprocessor conditional to select either
UART or USART and the other files use USART unconditionally.

While we're here, also fix the compiler error message when no valid ISR
name was found (it previously said "for the first UART" in all cases).
Match return value to type in available()
Updated Blink

removed the variable “led” and added some additional descriptive text
acording to the docs HttpClient::ready should return the inverse of Process::running()
Merge pull request #2066 from manuel-rabade/fix-httpclient-ready

Fix HttpClient::ready() return value
FindReplace dialog now search and replaces in all the opened tabs. Also pre-fill the find field with selected text
Unescape special characters in dependency files

When a path contains spaces (or other special characters, probably), gcc
escapes them with a \ in the generated .d files. This previously caused
problems when parsing these files, causing recompiles to happen even
when not needed.

This applies a rather simple approach to unescaping these strings, which
seems to be sufficient because the file format of the .d files is so
predictable (e.g., we don't actually split on colons or spaces when
parsing it).
Updated revisions.txt
Support TIMER1C

Some devices, such as the atmega2560 or the atmega256rfr2 have a timer1c
output. It seems this output is not connected to anything on the Arduino
Mega, but this allows using it on third party hardware nonetheless.