Relaxing ROS2 topic/service field name restrictions

The idea is that we would stay consistent in the core (probably keeping with the current underscore approach), but would open it up so that developers of downstream packages could use what they like. My two concerns with the current restriction is for migration (as @NikolausDemel pointed out), and the “getting started” cost for new users.

We are in an interesting situation with things like CameraInfo. When we originally ported CameraInfo to ROS2, we made it follow the current underscore/lowercase restrictions. If we relax the restrictions, we could go back to making it consistent with ROS1, but at the cost of being inconsistent with earlier versions of ROS2. I’m not sure which way we would go, though it is not my intention in this thread to hash that particular detail out. I mostly just want to see what people think about the current restriction.

That would be possible as well, though I still think it is a developer unfriendly. After all, there is no reason a message can’t have CamelCase fields, so for those who want to do that they could never have a warning-free build.