Feature request

Feature description

This was triggered by a discussion in the implementation of get_info_by_topic methods.
Related old issue: #496.

Summary of the current state:

• There's a way of ignoring ros conventions (i.e. avoiding adding rt/ in topic names, etc) when creating a Publisher/Subscription/Service/Client, by using ignore_ros_conventions qos option.
• In all the graph API, there's a way to specify if you want to query the "nice" (i.e.: demangled) ros names, or if you want to get the raw DDS names (or middleware specific names).
• The new rmw_get_publishers_info_by_topic has a combination of both usages. A topic name is passed, and part of the output is the type name. The first iteration used a no_mangle option, that indicates both if ros conventions have to be avoided or not, and wheather the type name is demangled or not (no_mangle=false: ros conventions + demangled output, no_mangle=true: don't apply ros conventions + show raw dds output without demangling).
• This is inconsistent with rmw_count, where there's no way to avoid ros conventions.
• rclcpp count_publishers does expansion, but does not remapping.

The issues are the following ones:

• Name expansion can't be avoided, so when avoiding ros conventions the result of a foo input is /foo (same as reported in Allow to create topics with "exact" topic name from rcl #496).
• If remapping is applied to publisher/subscription/etc creation, it should also be applied in the graph query functions. Don't doing so can led to inconsistencies when composing nodes. e.g.: one node creates a publisher in a topic, another uses the graph query api. The first gets the topic name remapped, the later doesn't.

Targeted users:

• Normal ros users: wants expansion+remaping+ros conventions applied.
• DDS user: don't care about any of them.
• DDS user that likes ros features: don't want expansion and ros conventions, but wants to be able to use remapping.

To satisfy the three use cases, the following options might be implemented:

• Implement only the first two use cases, switching between them with a boolean. Expansion and remapping API should be available in all clients.
  The third use case can be manually done by using the remapping API and switching off expansion+remapping+ros conventions.
• Use an option with three states.
• Allow expansion/remapping/ros conventions to be configured individually.
• The +exact idea could be used: http://design.ros2.org/articles/topic_and_service_names.html.

My vote: option 1. It covers the three use cases, and it's the easier one to implement.
A three state option can be added later, if we have a real use case of that.

Implementation considerations

We should review all the related API and apply one of the options to all of them (graph API and publisher/etc creation).
It might worth it to create a function that does remapping and expansion in rcl, and wrap it in all the clients. There are many places where we do expansion and remapping combined, so we might get rid of some duplicated code.