Feature: generate ROS2 compatible type naming

[TSC21]

Fixes #19. @LuisGP thank you for the tips. Please check if this solution makes sense to you:

1. -typeros2 option sets m_type_ros2 to true, which is defined in the Context;
2. If isGenerateTypesROS2 is true, meaning m_type_ros2, then it's used a scoped name generated from the IDL parser, which has the required valid structure to be used in the ROS2 context.

Requires eProsima/IDL-Parser#39 to be merged first.

[LuisGP]

@TSC21 Please, update the IDL-Parser submodule and I'll approve the PR.

[TSC21]

@TSC21 Please, update the IDL-Parser submodule and I'll approve the PR.

Ah yes of course. Will do

[richiware]

Also, please update the submodule IDL parser to the new generated commit after the squash (generated when merging the PR)

[richiware]

Please, update IDL parser submodule to the master's commit.

[LuisGP]

LGTM

[TSC21]

@LuisGP @richiware thank you both. This will definitely improve the experience for people using standalone Fast-RTPS apps linked in the same DDS domain as ROS2 nodes.

Before you do a release, I would like to add as a feature an option to install the script and binary system wide (in /usr/local for example), making a new PR. Is that something you can wait for or are you pushing to a 1.0.4 release already?

[LuisGP]

@LuisGP @richiware thank you both. This will definitely improve the experience for people using standalone Fast-RTPS apps linked in the same DDS domain as ROS2 nodes.

Before you do a release, I would like to add as a feature an option to install the script and binary system wide (in /usr/local for example), making a new PR. Is that something you can wait for or are you pushing to a 1.0.4 release already?

@MiguelCompany this message is for you :P.

[TSC21]

@MiguelCompany @LuisGP @richiware are you planning to document this?