Comentada la clse component y communicationPort.
Comentada la clase CEntity (no voy a comentar CMap porque tenemos aun que retocarla bastante mas). A ver por donde comienzo... Empece manteniendo listas de elementos tickeables y no tickeables, pero esto
me dio bastantes problemas (ya que hay componentes que no tienen tick pero procesan mensajes, y esto ultimo se hacia en el tick). Ademas, daba 2 vueltas para procesar todos los componentes 1 para el tick y otro
para el fixed. Parece una tonteria pero esto se notaba bastante en la ejecucion, incluso en la destruccion de las entidades tardaba un huevo. Total, como vi que estaba tocando demasiados ficheros y estaba haciendo todo
el codigo bastante menos entendible y complicado, decidir empezar otra vez y rehacerlo de otra forma mas sencilla.

Con el metodo de ahora el cambio practicamente no se propaga al resto de ficheros y es tremendamente eficiente. Yo se que David me va a matar por haberlo hecho asi, y la verdad es que no es la solucion mas elegante
por obscurece un poco el funcionamiento del codigo. De todos modos he comentado al maximo todo para que nadie se pierda (ya vereis que en realidad el funcionamiento es super sencillito). Lo que he hecho ha sido
mantener unos enumerados que indican el estado en el que se encuentra el componente y si tienen tick o no. La entidad utiliza estos estados y modos para setear el offset de una matriz de punteros a funcion que
en realidad contiene lo que tiene que hacer el componente en base a estos parametros. Lo he hecho de esta forma porque me di cuenta de que en realidad todos los componentes activos o bien procesaban mensajes
o bien hacian tick o las dos cosas, por lo que siempre tendriamos que hacer una llamada a funcion. De esta manera eliminamos las comprobaciones y hacemos que la ejecucion sea directa. Esto se podria haber hecho
con interfaces pero como tampoco queria perder mucho tiempo con ello lo he hecho asi.

Los componentes ahora pueden estar dormidos, despiertos u ociosos. Las clases derivadas de IComponent jamas deberian preocuparse por lo que hace la clase padre, tan solo deberian preocuparse de hacer lo que
crean oportuno antes estos eventos: onActivate, onSleep, onWake....

El onStart ahora solo se ejecuta una vez al comienzo de la carga del mapa. Cualquier cosa de inicializacion que necesitemos hacer que dependa de que otros componentes hayan hecho el spawn deberia hacerse ahi.

Los compontes ademas pueden tener tick, fixedTick, los dos o ninguno de ellos. Lo bueno ademas es que si el cliente redefine onTick/onFixedTick automaticamente se les llama. En caso contrario ni si quiera se hace
la llamada (eficiencia for de win!). [Finishes  #48853357].