Improve message generation experience

[wayneparrott]

To help improve the experience of developers working with rclnodejs I would like to:

1. Make it more obvious to users that rclnodejs generates corresponding javascript classes for each ROS2 interface (msg, srv, action) and that it is the user's responsibility to regenerate these js files when new or revised ROS2 interfaces are added to his system.
2. Improve the msg generation process

For #1a, I would like to add a section to the readme file and/or a wiki page that exposes users to the fact that msg files are being generated and it is the user's responsibility to regenerate msgs when ros2 interfaces change.

1b Consider including more info in the load_interfaces.js class error msgs when a msg file is not found. Currently rclnodejs throws an exception like this The message required does not exist: ${packageName}, ${type}, ${messageName}. Perhaps the error msg could provide info about how to fix the problem by regenerating msg files?

For #2, I propose we define generate_messages.js as a bin script, e.g.

// package.json
"scripts": {
  "generate-messages": "node ./scripts/generate_messages.js"
},
"bin": {
    "generate-ros-messages": "./scripts/generate_messages.js"
},

// generate_messages.js
#!/usr/bin/env node
...

Then a user could run

npm node_modules/.bin/generate-ros-messages

or create a package script such as:

"scripts": { "genmsgs": "generate-ros-messages" }

Looking for thoughts on the proposed action items and additional ideas for improving the user experience of working with msg files.

A final thought is to separate message generation to it's own node package that could be installed as a global package and run directly from commandline, e.g. generate-ros-messages.

[minggangw]

For #2, I propose we define generate_messages.js as a bin script, e.g.

This would facilitate to generate the messages instead of executing JS code 👍 we should expose this directly.