Added line checking and clearing

Changes:
-Overhauled checkLines() to work as intended, and faster than previously planned.
-All functions now work for most playfield proportions (I think). Some visually noticeable problems occur on excessively small playfields or when certain playfield-defining constants are not multiples of SQUARE_WIDTH (which equals 2 in this build, and may equal 3 or 4 in final single-player builds). More testing in this area should be done.

Notices: (*changed from last push*)
-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:
-Managing collisions detected when the player rotates the piece ("wall kicks", etc.)
-Clean up the code in general (especially in the body of tetris()) and shorten parameter lists.
-Create "hold piece" functionality and figure out how the player will activate it with their input.
-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 that is not the case, 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.