Add support for an axial grid layout.

The coordinate system used by the default HEX_SHAPE grid
layout in MOAI is unusual and sort of confusing. Of course,
all attempts to map hex grids onto rectangular spaces are
confusing. There's a really nice page with information
about hexagonal grids:
	http://www.redblobgames.com/grids/hexagons/

This attempts to implement something corresponding to the
"axial" coordinate system described there. This coordinate
system does not map as neatly to rectangular spaces, but it
makes the majority of the work one needs to do with
hexagonal grids simpler.

The existing MOAI hex grid layout looks like this:
	   1,4   2,4   3,4
	1,3   2,3   3,3
	   1,2   2,2   3,2
	1,1   2,1   3,1

This layout introduces a number of difficulties, of which
the most severe is that the hexes (x,y) and (x+1,y) are
not adjacent.

The new axial grid layout, by contrast, looks like this:

	1,4   2,4   3,4
	   1,3   2,3   3,3
	      1,2   2,2   3,2
	         1,1   2,1   3,1

The most surprising aspect of this is that, if you place
the 1,1 hex in the lower-left corner of the screen, the top of
that column is offscreen.  You could change the direction of skew,
so the entire first column would be on-screen, but then the hexes
immediately above 1,1 would have zero or negative coordinates,
which would be more annoying.

The axial system, however, offers a number of desireable
traits. Most obviously, the relationship between a given
hex's coordinates, and the coordinates of the hexes around
it, doesn't change. The hex northwest of a given hex is always
(x, y+1). The hex northeast is always (x+1, y+1). This
simplifies the work of doing pathfinding or similar operations
significantly, and most importantly, it removes the need to
perform expensive conditional tests in Lua code, which is a
major performance risk (especially on targets where luajit
can't do JIT compiles.)

The new work in MOAIGridSpace isn't fully tested, but it
appears to pass obvious sanity checks, and there's a provided
sample program to illustrate the usage.

There's one line of changes here that's not strictly tied to
the axial grid; the computations in getCellRect were adding
xOff more than they needed to in computing the right-hand
edge of a cell. (The cell's left edge already has any necessary
offset added; adding the offset again just makes the returned
rectangle too wide.)