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.
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.
Updated comments and function names

Notices: (*changed from last commit*)
-This code meets the main functionality of Snake and has no known bugs, and is therefore considered near completion. Besides optimization, this code will not get a lot of attention until input and output functions and aesthetic design decisions 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. Due to how orientation-independent most of Snake's mechanics are, this would be easy to change later.
-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 snake is then controlled with WASD.

To do:
-Optimized and clean up the code in general.
-Implement two-player Snake.
Created snake2Player

-This code being the first multiplayer implementation is rough in terms of organization and optimization but does not have any known bugs (excepting one bug on Windows, addressed below, which will not be fixed).
-This version of the code treats a long side of the LED array as the bottom of the screen. Due to how orientation-independent most of Snake's mechanics are, this would be easy to change later.
-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 bodies of getLeftInput() and getRightInput(). The snakes can then be controlled by WASD and IJKL respectively.
-NOTE: control of player two's snake does not work on Windows because the getLeftInput() call reads and discards all non-WASD input and then getRightInput() is called before another character is entered. The fact that player two's snake does work given proper input can be demonstrated by commenting out the first call of moveHeadCoords() or switching its line with the subsequent one. The final, joystick input will not cause this problem.
Renamed snake2Player.c to snakeTwoPlayer.c

Notices: (unchanged from last commit)
-This code being the first multiplayer implementation is rough in terms of organization and optimization but does not have any known bugs (excepting one bug on Windows, addressed below, which will not be fixed).
-This version of the code treats a long side of the LED array as the bottom of the screen. Due to how orientation-independent most of Snake's mechanics are, this would be easy to change later.
-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 bodies of getLeftInput() and getRightInput(). The snakes can then be controlled by WASD and IJKL respectively.
-NOTE: control of player two's snake does not work on Windows because the getLeftInput() call reads and discards all non-WASD input and then getRightInput() is called before another character is entered. The fact that player two's snake does work given proper input can be demonstrated by commenting out the first call of moveHeadCoords() or switching its line with the subsequent one. The final, joystick input will not cause this problem.
Renamed snakeGame.c to snakeSinglePlayer.c

I also included a delay into endGame for presentation. In final versions of this code, it would be represented by a single usleep call rather than a looped call to frameTest -- it is implemented as it is to make modifying the code to run on Linux or Windows computers easier right now.

Notices: (unchanged from last commit)
-This code meets the main functionality of Snake and has no known bugs, and is therefore considered near completion. Besides optimization, this code will not get a lot of attention until input and output functions and aesthetic design decisions 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. Due to how orientation-independent most of Snake's mechanics are, this will be easy to change later.
-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 snake is then controlled with WASD.

To do:
-Optimized and clean up the code in general.
Fixed nanosleep bugs. Code now compiles successfully.
Merge branch 'dev' of https://github.com/ECE1T6/game-o-matic into dev
Fixed bug with render.
Major refactor of lodev. Split up various functions
 into individual files and created header files for each
 .c file with appropriate include guards.
Merge branch 'dev'
Fixed conflicts: dev takes precedence
Conflicts:
	hidev/displayTest.c
	hidev/snakeSinglePlayer.c
	hidev/tetrisGame.c
	lodev/flushScreen.c
	lodev/hardware.c
	lodev/printScreen.c