experimental: add getStatusTopic method to retrieve action status

[ikwilnaarhuisman]

#1145 <- issue (which this PR fixes 50% of)

AFAIK the status of an action (aka the topic) is always defined in the same way: /{ACTION_NAME}/_action/status with message type action_msgs/msg/GoalStatusArray. So instead of having to create the topic yourself, you can just get it directly from the action.

This PR is experimental because I doubt that this is acceptable yet, but it works and gives a better idea than my vague description of the "missing functionality"

[ikwilnaarhuisman]

I want to achieve the same functionality for the feedback topic, but I'm not sure how considering the message type differs:

  getFeedbackTopic() {
    return new Topic<TFeedback>({
      ros: this.ros,
      name: `${this.name}/_action/feedback`,
      messageType: "", // <<<< unknown! doesn't even work.
    });
  }

// OR

  getFeedbackTopic(messageType: string) {
    return new Topic<TFeedback>({
      ros: this.ros,
      name: `${this.name}/_action/feedback`,
      messageType: messageType, // works, but feels dirty.
    });
  }

[ikwilnaarhuisman]

@EzraBrooks What's your opinion on this?

[EzraBrooks]

Personally I'm philosophically opposed to exposing the underlying _action namespaced topics in RWT because they're supposed to be ROS implementation details that clients do not mess with.

If there's a compelling reason to do this (which I'm not sure there is - I think perhaps you are operating outside the intended usage of Actions 😉), I think we should expose it at the protocol level in rosbridge/rosapi (cc @sea-bass @bjsowa) rather than adding a function to Action that returns a Topic - I really appreciate that our ROS 2 Action implementation in our client libraries can be disentangled from Topic, Service, etc. unlike the original actionlib implementation.

If it were done at the protocol level, then the roslibjs implementation could emit a status event on the Action class, instead of returning a separate subscribable Topic.