Update Svelto.ECS From an old version

This applies to the newest Svelto 2.5 version. It's a collection of tips, may not be comprehensive:

• Old versions of Svelto used to get the implementors from the EntityDescriptor. This is quite old, it's a while that the implementors are now passed directly in the BuildEntity function.

• There is no difference anymore between BuildEntity and BuildEntityInGroup. It's just BuildEntity with an optional group ID parameter.

• Entity ID as integers are no more. They are now EGID. EGID it's a structure that includes the Entity ID for a specific group and the ID of that group. Two entities cannot have the same ID in the same group, so while two entities can have the same ID while belonging to different groups, it must paid attention to use functions like SwapEntityGroup in these scenario.

• The entity EGID is not a constant value, therefore cannot be used as key for data structures. EGID changes when the entity changes group.

• it's better to design Entities knowing before hand if they are going to be used among different groups. This because re-using the same ID on different groups is wise ONLY if the entity will never change group, otherwise it can generate conflicts and end up in unexpected error throwns

• The same entity cannot belong to more than one group at the same time

• Engines Root cannot be used as IEntityFactory or IEntityFunctions directly, those must always be generated through the EnginesRoot GenerateEntityFactory() and GenerateEntityFunctions() methods.

• EntityDescriptors don't need to be instantiated anymore, it's used as generic parameter in the BuildEntityFunction. _entityFactory.BuildEntity(player.GetInstanceID(), player.GetComponents());

• GenericEntityDescriptor cannot be used directly, it's an abstract class

• GenericEntityDescriptor can generate EntityViews, EntityViewStructs and EntityStructs

• Since Svelto 2.5, EntityViews are sort of deprecated. They may have a reason to exist, but their use should be very limited and replaced by EntityViewStructs.

• By using EntityViewStructs you won't be able to hold a reference of the EntityView in any way.

• The reason to use EntityViewStructs over EntityStructs is purely design related. EntityViewStructs are still fundamental to wrap implementors that act as a bridge between the platform and the engines. EntityViewStructs may still be beneficial to help write modular code. However once the good design practices are well understood, switching to very modular entity structs can yield various benefits.

• When the EntityDescriptor cannot be determined at compile time, it's possible to use the concept of EntityDescriptorInfo. It's usually linked to the use of GenericEntityDescriptorHolder (Unity only). Allows to enable Entity Polymorphic code, which means that the same code to create entities can be used for several entity types.

• Groups must now be extensively used. I expect groups to solve every day problems, substituting custom data structures.

• when EntityViewStructs are used, two different entities can be built with the same implementors so that the same data can be used through two different groups. It's an allowed trick, useful if used carefully.

• The RemoveEntityComponent is gone! To remove a Entity the IEntityFunctions implementation must be used and passed by constructor to the engines.

• MultiEntityViewsEngine and SingleEntityViewsEngine are left for back compatibility, however MultiEntitiesEngine and SingleEntityEngine must be used normally. The main difference is that the latter can manage structs.

• By no means MultiEntitiesEngine or SingleEntityEngine are meant to "sign" the engine. Actually they must be used as less as possible.

• EntityStruct must hold only value and primitive types, they don't need implementors nor component interfaces.

• EntityViewStructs must hold only component interfaces.

• component interfaces must hold only getters and setters to value types (this includes DispatchOnSet and DispatchOnChange).

• EGID are simple to use, if you have the entity ID and the group ID you can always create an EGID through new EGID(id, groupId)