image_transport publisher nodes should support subscriber specific compression config

Overview

Suppose there is a setup with one image transport publisher node, and one subscriber node, which uses the theora std to compress images. If we add a second subscriber using the theora std, it has to use the same config (bitrate, quality, etc) as the subscriber 1.

Workarounds for now

Right now, this can be implemented using republish nodes. We could the actual publisher node, then several republish nodes that publish the compressed topics with the required configs.

Implementation suggestions

The subscriber can make a service call to the publisher, requesting the config it needs. The publisher should spin up the required topic with the config, and reply with a boolean status. If the response is positive, the subscriber should start listening in on the new topic and the required config.

The publisher can then stop the new encoding if no subscriber is listening in on it.

Open to design suggestions @ahcorde @clalancette @mjcarroll

Start by reading the image_transport publisher and subscriber node paths, then compare their behavior with the republish-node workaround described in the issue. Define and validate support for two subscribers using independent theora configurations, including stopping an encoding when no subscriber remains.