Switch the example game to a different font

The new font, Alagard, was created by Hewett Tsoi. I downloaded it from here:
http://www.dafont.com/alagard.font
Add the isAnyOfSeveralKeysPressed function.
Make the PLAYING state do something

We now have a very simple player object (a state machine) which has a
position, size and speed. It moves around the screen in response to the
keyboard.
Pass a StateMachine as first param to per-state functions

Changed the expected signature for the enter, update and leave functions
that you provide for each state:

enter()     --> enter(sm)
update(dt)  --> update(sm, dt)
leave()     --> leave(sm)

Where 'sm' is a reference to the StateMachine instance that the state belongs
to. This helps avoid the need to have a global variable for each state machine
instance, which is an improvement.
Pass a StateMachine as first param to draw functions

If the current state of the game state machine has a draw() function, the game
loop will automatically call it. Previously draw() was called with no
arguments. This commit makes the game loop pass a reference to the game state
machine instance as the first parameter of the draw function. This matches the
new behaviour of the other per-state functions, which also now take the state
machine as their first parameter.
Change state functions to take the state machine as their first param
Specify measurements in terms of pixels instead of tiles
Add time functions to base.js
Make every state machine keep track of time

Every state machine now has enterT and stateT attributes:
- enterT is the time it entered its current state.
- stateT is how long it's been in the current state for (as a convenience).

These are automatically updated by the start() and update() methods of the
state machine. They assume that ludum.updateCurrentTime() is being called once
per frame.

This change lead to a refactoring of the gameloop code. We no longer create a
state machine the we export; instead we require users to create and populate a
state machine which they pass in to the startGame method as a parameter. A nice
side effect is that the game code gets simpler from this too.
Try to get panning around the level working properly

The aim is to have the camera follow the player as far as possible, up to the
edge of the level, when they move outside the middle 50% of the viewport. It's
not working properly yet.

I've put in some code for drawing a background and some debugging info about
positions being displayed up in the top-left corner.
Get camera panning working properly

Fixed a typo in the background drawing - a 'y' where it should have been an 'x'
- which was giving the appearance of moving diagonally some of the time.

Fixed the calculation of the inner bounding region of the viewport.

Initialise the viewport offsets correctly in the enter function for the PLAYING
state.