Define the component API of each system

[gerkey]

In the course of migrating a plugin from Gazebo to Ignition (#80), one source of confusion was determining which component(s) a given system will read from and/or write to. More than once, I did something like this (imaginary example as I can't find the details of a specific one that I encountered):

1. Decide that I need some data from an entity, say, the temperature of a link.
2. Find that there's a Temperature component that sounds promising.
3. Call EntityComponentManager::Component() to retrieve the component.
4. Try reading from the component via Data() and get a segfault.
5. Figure out that the component pointer returned by Component() is null, which presumably means that the component doesn't exist. My bad for not checking the return value.
6. Check the return value from Component() and call CreateComponent() to add the component in question.
7. Read from the component via Data(), which works! But notice that it just gives me 0, which is wrong.
8. Realize that there's no system on the other side writing to the component and that I've been trying to do the wrong thing all along.

The same can happen in the other direction, when I want to write some data to a component associated with an entity: I can create the component and happily write to it all day even though no system is reading what I'm writing.

We should define the component API of each system: what components will it read from and write to, and what additional semantics are needed to interpret those data?

The same problem exists with ROS (and other flexible messaging systems): unless I know which topic name and type are used by a node, I can end up subscribing or publishing to the void instead of actually interacting with anything. In ROS it's addressed by manually documenting a node's message API (e.g., robot_state_publisher). Some sort of compile or run-time enforcement or notification would be great (e.g., You're writing to a component that has no readers), but I can understand why that would be difficult or impossible, in which case manual documentation is probably the best we can do.