Eat closest dot behavior

[ll-nick]

Closes #25

This adds the EatClosestDotBehavior.

The behavior itself is pretty simple as the heavy lifting is done within the A* class. Here's a brief summary of the changes:

• There is now a getter for the TileType in the maze class. Before, it was only possible to check for walls, not for dots.
• Add a predecessor to the cell class allowing to generate a path by traversing from the goal to the start via the predecessor property
• Add a shortestPath function. computeDistance is now simply a wrapper that returns the length of the returned path
• Add another interface to the A* class computing the path to the closest dot reusing most of the existing A* logic
• Continuously update the maze withing the A* class since we now need the dynamic info about dot positions. It's just a pointer so it shouldn't be a big issue.
• Add the closestDotBehavior to the Pacman Agent. For now I just added it to the main priority arbitrator. We need to change that after adding Add cost estimator #27
• Yet another rename for clarity: the A* distance is now called mazeDistance because I replaced the function that used to return the euclidean distance by the manhattan distance since it's a better heuristic for A*.

I think that's about it. A couple of points I'm unsure about:

• Should we also consider power pellets here or do we do that separately or not at all?
• Is there a sensible heuristic for the closest dot path? Right now I just use 0 which is obviously a crappy heuristic but I couldn't think of anything else and I'm not sure if there is a better solution.

[ll-nick]

About the heuristic: Using the manhattan distance from the start to the cell we are about to expand next might be slightly more useful than setting it to 0. With the 0, we basically have a breadth first search. It works but might be a little confusing.

[orzechow]

Thanks! Looks good!

Some minor suggestions, feel free to consider them and merge right away