Implemented "wall kicks" (i.e. rotation clipping resolution)

Changes:
-Implemented "wall kicks" in a standard, if old-fashioned, manner. If a rotation causes a collision, the code looks for valid positions for the active piece right and then left of its current position. If no valid spaces are horizontally adjacent, the rotation is not processed. The "I" piece is allowed to kick two spaces to the right or left to account for the fact that it can clip two squares deep into a wall. This should resolve all remaining clipping issues. Some more information and illustrations for wall kicks can be found at http://tetris.wikia.com/wiki/Wall_kick

Notices: (unchanged from last commit)
-This version of the code treats a long side of the LED array as the bottom of the screen. This may not be the case for the final single-player version of Tetris, but it makes testing the code easier and can be adjusted for a two-player version of Tetris with two playfields. I can reorient this code without much trouble later.
-This version of the code includes a global 3D array to temporarily skirt the development complications of a planned tetrominoes.h, which would just include that 3D array.
-This version of the code includes a placeholder menu. It also includes test input handling for Windows, which can be enabled in Windows by de-commenting everything below the two "/*Windows:*/" tags and commenting everything below the "/*Linux:*/" tags, as well as de-commenting the body of getLeftInput(). The keybindings are as follows:
A - shift left
D - shift right
S - "soft drop" (shift one space downward)
W - "hard drop" (shift all the way downward and spawn a new piece)
Q - spin counter-clockwise
E - spin clockwise

To do:
-Clean up the code in general (especially in the body of tetris()) and shorten parameter lists.
-Look into cause of inconsistent response to input (particularly rotations?) and consider solutions. My current guess is that dropTimer just needs to be higher to process input at a higher fidelity, which should not be a problem on the Raspberry Pi as it should be able to run the code faster than Code::Blocks for Windows on my laptop. If it does not run fast enough, one worst-case solution would be moving getLeftInput to the end of each input path (including input==0) except for automatically triggered soft drops; this may give a more consistent response to input at low values of dropTimer, but introduce an overall input lag. I need to test more here to be certain of the source of the problem.
-Consider options for displaying the next piece(s) and the held piece, if such functionality is desired. The code for handling this data would be quite simple to write, but the code to display the information would be dependent on screen size and layout. Not a priority.