Avatar also using the Animation classes, refactoring the animation class use.


This pullrequest is a major refactoring on the Avatar class:
The Avatar rendering on map is done by multiple Renderables instead of one Renderable before.
The advantage is faster equipment changing times,
because not the whole spritesheet must be recreated
starting with the base clothing and applying each item sheet onto it.

The avatar has a list of different Animationsets now, one for each equipment piece.

So on rendering the each equipment piece is drawn on its own. To preserve the order of equipment items drawn, the rendering code was also rewritten. Instead of sorting the items by location, the item locations are mapped to a huge number, so you can modify the number to a certain degree at one item but still preserve its position in the list.

Managing the graphics was completely removed from the EnemyManager class and attached to the AnimationManager class, which delegates this to the new introduced ImageManager class.
An attempt was made to also reduce the intermap loading times by introducing lazy loading mode.
So the workflow for getting animations to screen is now this
```
string animationname = "animations/path/to/file.txt "
AnimationManager->instance()->increaseCount(animationname); // // register this animation for lazy load.

... // do a bunch of stuff, such as map changing.

AnimationSet *set =  AnimationManager->instance()->getAnimationSet(animationname); // get an animationset, this is a handle for all animations defined in one animations file, i.e. on enemy.

Animation *a = set->getAnimation("run");

a->advanceFrame();

... // later we want to unload this animationset and image 
// make sure 'set' and 'a' are not referenced anymore:
AnimationManager->instance()->decreaseCount(animationname);
AnimationManager->instance()->cleanUp();
// and both the image and the animation definition are gone
```

As the Enemymanager doesn't have to handle the images anymore, the information about it is not found in the enemy definition file anymore, but in the animation definition file.

Additionally to these changes, I also tried to remove most of the warnings as of static code analysis, so hopefully I did not break anything as with the enemies path finding algorithm.

Additionally a travis.yml config file was attached.
This was the technically part of #19, now this repository must be registered at travis. Unfortunately this can only be done by the original repository owner, @clintbellanger himself.

To sum it up for external view of modders:
  * Defining the image is in animation class now, not in the enemy definition file.
  * Also you need to have separate animation definition files for each item of the hero. This can be copy-pasted if you're using a gridlike layout of your items, otherwise you need to specify each on its own, see the packer tool for it.

---

This pullrequest should probably not pulled now, as the transforming in the Avatar class was not tested at all, but I'd rather want you to comment on my intended way of refactoring the code:
  * This reduces equipment loading times
  * This reduces map change times, when similar enemies are on both maps.