Make building of subscription events more robust

[cwecht]

With these changes, it doesn't matter in which order tracepoint related to subscription events come up. This is helpful especially if one is playing around with the order of tracepoints in the code.

[christophebedard]

I like this approach, I would have assumed that the ordering would have been strictly monotonic, but if that isn't this case, this will correct for that.

I generally tried to order the tracepoints to match the data flow. When publishing, the message goes from rclcpp down to rmw and the middleware; when taking a new message, the message goes from the middleware up to rclcpp. This also makes a lot of sense when processing the trace events, but there is no strict guideline, so robustness is definitely good I think.

[cwecht]

I wanted to move up the rclcpp_take tracepoint to the beginning of the the function call rather than the end so that I could measure the time between the node being notified about new data being available and the completion of the read operation. Also, with rclcpp_take begin placed that way, one can now somewhat measure the latency introduced by the notification/executors machinery. Anyways, with these changes here, one is free to move around the trace point as desired if such use cases are of interest.