Messages are now managed through an object pool

They are built at initialization time, will be used during execution and
will be destroyed when the game finishes.
Known issues, which will be done soon:
- If the pool is empty and a new message is requested, no message is
returned (this will change).
- Initialization is manual for now, hardcoded. They will be built from
data files.
Messages register themselves into the pool at init

Similar to components registering themselves into the ComponentFactory.
Now both message pool and component factory allow several calls to add
instantiators, also allowing for multiple inclusions of a compilation
unit (including a certain message or component header in multiple
places).
Adds a policy to deal with extra demand on the pool

This policy creates a new message and keeps it for the rest of the
execution.
Creates a properties map class to parse data

Refactoring from prior LevelData, there's now a properties map which
stores pairs of data. It's now used by other classes including
LevelFactory, but also the brand new Config class and will be used in
the future by other ones.
There's also a Config file to get closer to a data-driven architecture,
defining in a data file the name of other relevant files.
Message instances count at init is now data-driven

The amount of messages to be created at initialization for each type is
defined in a data file.