new model: Path;
prepared for rendering. will be used to show possible path of die on
board.
one path object per possible move.
use two different colors: normal & main. main-path will be rendered last
of all possible moves to be on top (for picking).
extended Vector class

additional operators (+,-,*,==)
equal-method for comparison
2D-constructor
consolidation of tile position

tile position marks center of tile, now (like with die).

+reformatting
+preparation for path drawing
renaming according to style (all caps denotes constant)
made objects removable from scene

when adding an object, scene returns a unique id.
this id may be used to remove the object again from the scene.

+added dummy path for testing
+removed unnecessary file 'handler.hpp'
redone color management

default colors are now in namespace ColorTable instead of being defined
as static members of the color class. advantage: can use as values to
initialize other global members like static member variables.
this did not work before, because of static variable initialization
chaos caused by undefined order of compilation of different units (i.e.
cpp files).
long terms short: in the case of something like

static const Class1::color = Color::GREEN

where GREEN would be a static member of Color itself, it could happen,
that this line gets compiled before 'knowing' the value of GREEN (i.e.
before 'static const Color::GREEN = ...' got compiled somewhere else).
additions to 3d vector

* copy constructor
* shorthand copy in rotate() if angle equals 0
* possibility to call glVertex3f directly with vector content
ok, copy constructor call done right...
implemented drawing of a single path object

awaits a position and a relative move.
all directions (with x first or y first) are supported.

next: get possible moves from engine...
some refactoring + map matching colorId (picking) to dieId
reverted removal of Board::clicked ...

+ reformatting
+ refactoring of private member names to fit nomenclature
changed explicit PlayColor in evaluation to implicitly stored value

that way, the game state is always completely stored, since the game
holds the information itself, who is the next player.
that way it is additionally possible to correctly state if a given move
is valid.

+ formatting
Object -> Model; AnimObject -> AnimatedModel
implemented method to get possible moves for given die (id) in current
situation.
corrected die orientation in board setup (now equal to rules and engine)

+ implicit setting of _playColor and IS_KING for dice depending on given
dieId
path drawing working (at least in starting position)

- engine tests in 'moveIsValid' for correct player color (black or
white)

- paths are drawn and kept in in list to be removed afterwards

- paths are ordinary models and can be clicked (may be used later to
actually move the die along the selected path)

drawing of paths needs more testing once dice lie on other positions
than start setup.

there is also more testing to do on the selection of valid moves in
engine (test for boundaries, look at TODO...)