Optimized checkLines

Changes:
-Added a "break;" to checkLines so it doesn't have to span the length of every row. This is totally a significant change that deserves its own commit.

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:
-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.