Added example of typical zmon structure

Here is simple example for zmon case. We have at least main 3 parts : mon_pub, mon_node, mon_sensor_xxx

mon_pub : publisher to the world about current cluster (many mon_nodes) information (pub/sub) where sub will be webpage or other app which needs this information

mon_node : is one of many nodes in cluster. mon_node sends information to mon_pub

mon_sensor_xxx : is actual sensor which is monitoring part of system

Output of this simple application from examples/zmon_example.c is:
```
14-07-21 10:31:33 mon_pub=3
14-07-21 10:31:33 mon_node=3
14-07-21 10:31:33 mon_node_sensor_cpu=3
14-07-21 10:31:33 mon_node_sensor_mem=3
14-07-21 10:31:33 mon_node_sensor_net=3
```

As one can see all keys (as expected from zgossip) all keys are redistributed to all nodes. Well done zgossip. :+1: 

But in case of zmon, it is not what we wanted. We would expect to have 
1. no key/val on mon_node_sensor_xxx
2. 3 key/val on mon_node (asctual monitoring values for current node)
3. one key/val (where val would be for example json format string about one node in this case)

Note that in 3. point i understand that zgossip should not do this for us. Just to see problem with zmon

So my idea is to have different way how we publish information
1. "PUBLISH" : is nice and perfect, but i would add some more (more limited one)
2. "PUBLISH_PARENT" : key/val is published to parent only (actor which is doing BIND, maybe)
3. "PUBLISH_CHILD" : key/val is published only to remotes (CHILDS) and not to PARENTT

With these commands i can imagine to implement very nice zmon app using zgossip

Sure here i have to implement transition from "mon_node" to "mon_pub", but this is easy since, "mon_pub" can wait on event "DELIVER". And "mon_node" can send monitoring (updating key/val ) information and publish it to PARENT only.

I hope it is clear.