Add Fire, Rotation. Document Health, Hunger, Position, Velocity, Level, Solid

components-system branch: Big thanks to @Zidane for starting components up
Documented some values with "value in {link org.spongepowered.api.math.Vector3i Vector3i}" due to the fact that new people may not be used to using Vector3i
c/p from forum http://forums.spongepowered.org/t/component-system-and-minecraft/76/70?u=zerot:

There is almost no need to store the exact monster type as a component. Systems should not use it, and in the case you do need a specific entity type(for what purpose I would have no idea) you could have a simple NameComponent/TypeComponent which stores the name of the entity. There is no need to optimize this, because it should (almost) never be used. I could see it used by plugin developers that don't understand the ECS structure well, but it should be discouraged.

In an ECS you never want to ask "is this entity a specific type". Instead you will want to ask "Does this entity have this aspect" and aspects are represented by components.

For the rendering/model type sent to the client you would have a different component. And you should never use that component to see what kind of entity it is. It should only be used to tell the client what to render.

> the components that extend the base entitycomponent as well (Once again, I would vote for them being classes as well, since they only store values, and have nothing to do with the logic)

I would argue against that. How it is stored can be an important implementation detail. e.g. with the RenderComponent it makes sense to store the internal value as an int or enum that is used for the package sent to the client, but for the API it makes no sense to expose it like that. You would want to expose it as a string and convert it to the int/enum value when it is set. The render system would use the int/enum value instead of converting it every time it is needed.