Robotics Systems Commons

Current implementation of logging doesn't play nice with log4cxx,
i.e. a LoggingSystem that already provides hierarchical loggers.
In this case explicitly setting the log levels down the hierarchy,
overrules any settings made in log4cxx's own config files.

Hence, I modified the code along the following guide lines:
* - loggers are created lazily on demand
The @LoggerTreeNode@ LoggerTreeNode maintains the hierarchy (and explicitly set log levels).
However, Loggers themselves will be only created by @LoggerFactor::getLogger()@. LoggerFactor::getLogger().
* @LoggingSystem::createLogger@ - LoggingSystem::createLogger expects second argument now with desired log level.
LoggingSystems like log4cxx want to ignore this argument, but rely on their hierarchy.
* - bool @LoggingSystem::needsRecursiveLevelSetting()@ LoggingSystem::needsRecursiveLevelSetting() is used to choose
**
- recursive TreeLevelUpdater for non-hierarchic LoggingSystems
**
- SimpleLevelUpdater for hierarchic systems
* - Do not use shared_ptrs for @LoggerTreeNode::assignedLevel@. LoggerTreeNode::assignedLevel.
This was only used to know whether a level was explicitly set. Use a bool instead.
* - Simplified @LoggerTreeNode::Visitor@
** LoggerTreeNode::Visitor
- parentLevel argument was never used -> removed, can be retrieved by node->getLevel()
**
- visiting includes called node -> reduces code duplication

Consequences:
As long as no log levels are set explicitly by rsc means, the
LoggingSystem can continue to use its own configuration mechanism.
Calling @setLevel()@ setLevel() overwrites these settings, but only for the current node.