Rewritten piece controllers using sti, and refactored initialise game co...

This is quite a big change behind the scenes. Here's what the code does:

1. Removes a column from the Piece table called "piece_type", and switches it for a column called "type". It's a small change on the surface, but it enables some fancy magic using "Single Table Inheritance" or STI. More importantly, it'll break the existing game code. So you'll need to run
``` ruby 
rake db:migrate 
```
and then empty the database. I *think* that this command will do this:
``` ruby
rake db:reset
```

2. Breaks apart the Piece model into lots of smaller models named after each Piece (this is the STI magic happening here). This will enable us to keep the logic for each piece separate, which is nice because different people can now work on different pieces. 

3. Rewritten the initialize_the_game! method in the game controller to streamline it. I've now put all the initial game state parameters into a constant array called INITIAL_BOARD_PIECES, and have written some code that loops through this and generates the board.

One question about (3): I think we can streamline the initialize_the_game method further, by separating out the image filenames from the array, because those should be inferable from the colour and the piece type. I've created helper methods in each piece model to return the image name, but I'm not sure what's the best way to use them, because the initialise method is creating the pieces in the db, and we want to ensure that the image filenames get inserted at the same time. Any thoughts?