[jsk_topic_tools] Add topic_hz_converter for keeping the topic hz stable

[tkmtnt7000]

I add topic hz converter.
Unlike topic_tools/throttle, this node can increase and stabilize the frequency of a particular topic.
For example, a topic in sensor_msgs/Image that is publishing at 10 Hz can be set to 30 Hz by continuing to publish the previous image topic.

And this node support multiple topic type.

[k-okada]

please add test code

by the way, why we need this?

1. if we use approximate sync, increasing time window
   http://wiki.ros.org/message_filters#ApproximateTime_Policy

2. if we ros node that expecting to run 30hz, but it run main code based on topic call back.

(defmethod intelligent-action
 (:init () (ros::subscribe "image" #'send self :cb))
 (:cb (msg) (setq cb-msg msg) (do-intelligent-job)) ;; expecting to run 30hz
)

Then you should write 30hz, loop and use latest sensor topics somethign like

(defmethod intelligent-action
 (:init () (ros::subscribe "image" #'send self :cb))
 (:cb (msg) (setq cb-msg msg))
(setq r (ros::rate 30))
(whille (ros::ok)
  (do-intelligent-job (*ia* . cb-msg)) ;; call do-intelligent-job 30hz, with latest image sensor data
  (send r :sleeep)
  (ros::spin-once))

Sometime peope uses one-shot-subscriber for this purpose

(whille (ros::ok)
  (setq cb-msg (one-short-subscriber "image"))
  (do-intelligent-job cb-msg) ;; call do-intelligent-job 30hz, with latest image sensor data
  (send r :sleeep)
  (ros::spin-once))

but it is not a good practice.

[knorth55]

@tkmtnt7000 can we use #1748 instead of this PR?