ISystem implementation

This implements a basics ISystem, in its current state it is simply a way to handle the Components one system contains without having to reimplement it in every System. Furthermore there are some changes to IComponent adding a ComponentID to this class. Currently the ComponentID is a string, thought it could be changed into hash-function calulated at compile-time later on by changing SET_COMPONENT_ID(ID).

Since there is no PM function I will just write this here:
I am thinking of expanding the ISystem and the concept behind it a bit further, though the changes required are rather drastic, therefore I wanted to ask beforehand if they are fitting into the general design you want to follow with Sigma or not.
Basically I am thinking of cutting out the Update and ApplyForces Functions and putting that logic either into the Systems itself or into Subsystems, those would basically just be methods, that take 1 or more Components of a given Entity and manipulate them based on what they try to accomplish. Furthermore it would remove the need of the System itself to know the type of Component it is handling outside of the actual logic which would allow to make ISystem into a non-template class. The major point of that is, that it would make it easier/possible to create a central SystemManager/ComponentManger or something similiar, the function would be comparable to the Current FactorySystem in that Systems would register with it and supply a list of Components they are responsible for. That way (Sub)Systems would be able to retrieve and manipulate Components via this ComponentManager that are not their direct responsibility but still need to be manipulated by them. One example for this necessity that comes to mind would be a Position Component, which would be needed by both the Physics and the Rendering System, it could now be added to either of them, while allowing the other System to retrieve it whenever needed.