Adjusted spawn location to standard

Notices: (*changed from last commit*)
-This code meets the main functionality of Tetris and has no known bugs, and is therefore considered near completion. Besides optimization, this code will not get a lot of attention until certain decisions (outlined below) are made or until input and output functions are finalized later in game-o-matic's development.
-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.