Feature: Async/await API for action clients

[iv461]

Work in progress: an async/await-based API for action clients that supports the following:

• awaiting the result of setting a goal
• receiving feedback
• obtaining the final result
• receiving feedback

I currently don't think I can finish this PR due to multiple bugs in rclcpp as well as the specification of the actions being implemented incorrectly:

• Deadlock occurs when chaining send_goal requests. This is caused by non-reentrant mutexes being held locked unnecessarily during user callbacks. This was fixed in the rolling version (async_send_goal deadlocks ros2/rclcpp#2796), but Tomoja Fujita says it won't be backported (async_send_goal deadlocks ros2/rclcpp#2796 (comment)). Unfortunately, this conceptual issue is present in many places in rclcpp.

• The specification of the actions protocol, more precisely the sequence diagrams, unambiguously specify that the server should only start sending feedback messages after the client has sent a result request. However, the current ROS implementation does not adhere to this specification. This standpoint is also shared by Janosch Machowinski (Status is Never Set to Executing if ros2 action rclcpp_action ros2/rclcpp#2782 (comment)).
  It deviates from the specification by enabling the client to receive feedback messages before the result request has been sent.
  This means a sensible async/await API such as:

auto maybe_goal_handle = co_await action_client.send_goal(goal, 2s);
if(maybe_goal_handle.has_value()) {
   auto goal_handle = maybe_goal_handle.value();
   for(auto fb: co_await goal_handle.get_result(20s)) {
       if(fb.is_feedback()) {
          
       } else {
            /// We got the final result
            auto result = fb.result();
            break;
       }
   }
} else {
   /// Goal request rejected
}

would have a race condition, although it adheres to the specification. Feedback messages may be received before the get_result function is called, meaning they may be lost. This issue has been discussed here, and a fix has been proposed.

• An API for cancelling send_goal and cancel requests (similar to regular service calls) is missing. Currently, it is not possible to cancel callbacks or delete a pending goal request. If the server dies, the client leaks memory. This issue has not yet been resolved in the rolling version, as there is currently no way to delete items from the pimpl_->pending_goal_responses map added here. Fixing this may require a fix in rcl

Minor TODOs:

• Workaround for coroutine-related GCC 11 bug (error: no suspend point info for ‘‘co_await’ not supported by dump_decl<declaration error>’ 134 | auto r2 = co_await f2;), for Humble

[iv461]

Closing in favor of #17 that pathes rclcpp to solve the above issues.