Improve subt_example to support broadcast and multiple port binding

[AravindaDP]

Current implementation of subt_example_node has following deficiencies.

• While it's technically possible to use <robot_name>/create_peer service to send messages to broadcast address, these messages do not get published on <robot_name>/broadcast/recv topic.

• Sending arbitrary/proprietary messages on broadcast under default port is discouraged as these might get incorrectly interpreted by base_station as artifact reports. So at a minimum broadcasts need to happen in a separate port than default. Broadcast and "Error parsing artifact" #502

• subt_example_node only binds to default port and create_peer service doesn't support specifying target port.

I propose following enhancements so that this node can be used as a generic gateway between ROS and CommClient so that even python nodes can easily use CommClient using a ROS API. #35

(Minimum) Support broadcast send receive on a dedicated port

• Bind to additional port dedicated for broadcast at Controller constructor https://github.com/osrf/subt/blob/master/subt_example/src/subt_example_node.cc#L149

• If remote is broadcast send messages on this dedicated port at subscriber handler https://github.com/osrf/subt/blob/master/subt_example/src/subt_example_node.cc#L221

• At CommClientCallback search for peer broadcast and publish on it instead searching for a peer equal to _srcAddress if receiving port is broadcast port https://github.com/osrf/subt/blob/master/subt_example/src/subt_example_node.cc#L318

(Full Enhancement) Support binding and creation of peers on arbitrary ports

• Bind on additional ports at node launch time using rosparam. (Exposing a ros service call for additional port binding on demand is possible but makes the things complicated with maintaining publisher topics)

• Extend create_peer service request to include remote port. This will subscribe to <robot_name>/remote/port/send and make publishers on <robot_name>/<local_port>/remote/recv for each local port bound to above step. (So receiver publishers are created for all locally bound port for respective remote when first remote:port pair is used. Additional create_peer with different port but same remote will have no effect.

• Like wise beacon port binding and rssi topic will be unique for a given remote.

• At subscriber handlers, pass in remote port. https://github.com/osrf/subt/blob/master/subt_example/src/subt_example_node.cc#L221

• At CommClientCallback route messages to correct publisher based on remote address and destination port. If no peer connection found and broadcast peer is available, publish on it.

Let me know your thoughts. I could give it a try for a PR if this is a welcome enhancement. I would probably limit it to minimum enhancement I have proposed above since that's the minimum I require at this stage.