Fixed priority inversion by removing the boolean flag in RosPubChannelElement and added unbuffered publishing

There was a priority inversion in the `RosPubChannelElement` as a real-time thread that called `signal()` had to wait until the non-real-time publish activity has finished it's loop due to the mutex in `RosPublishActivity` (9cb131209f9de887999fd85439ed487e9fd00ad6). As discussed with Ruben today, the boolean flag is not required at all as just calling `publish()` on each publisher is not expensive if there are no new elements in the queue (a4e8b961895e6de88a8f281de76c64cc7aa76778).

The third commit moves the potentially large data object containing vectors etc. from the stack of the `publish()` method to a member variable. This should reduce the number of reallocations if subsequent messages contain vectors of the same size (c210eb33dc38527b2e3d45264f47da28da291363).

Last but not least, I added support for unbuffered publishers, where the thread writing in the port directly calls the ROS publisher's `publish()` method. This is not real-time safe under certain conditions, but there are certainly use cases (e.g. when publishing from a non-real-time thread or for simulation). Note that you still can specify a buffer size for roscpp's internal buffer mechanism by increasing the `size` property of the `ConnPolicy`. I also added a `ros.topicUnbuffered(topic)` operation to the rtt_ros service (888e9ffa76d2e92fe01a56b9e11bc3f13b97d19b).

By the way, shouldn't there be `size` argument even for data and unbuffered variants of the `ros.topic*(topic[,size])` operation, as size is always passed as `queue_size` paramter to the ROS publisher? Do operations support optional arguments to not break existing scripts?