Fix issues with resuming async tasks awaiting a future (backport #1469)

[mergify]

Description

Fixes #1467
Fixes #1405
Fixes #1462

Is this user-facing behavior change?

• The _pending() method in Future has been renamed to pending()
• The user no longer has to do any workarounds with waking up the executor when a coroutine gets stuck awaiting a future that is already finished.

Did you use Generative AI?

Some of the comments and docstrings might be partially written by Github Copilot.

Additional Information

For #1467, I propagate a guard condition from a task to the awaited future and add this guard condition to the wait set in the executor. When a future is completed by an entity not controller by the executor (e.g. a separate thread), the guard condition is triggered and wakes up the executor so it can resume the task.

For #1405, I just had to make sure the task is not yielded from _wait_for_ready_callbacks when it is not ready to be resumed, hence the Task.ready() method.

EDIT: Check this comment

---

This is an automatic backport of pull request #1469 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 9695271 has failed:

On branch mergify/bp/humble/pr-1469
Your branch is up to date with 'origin/humble'.

You are currently cherry-picking commit 9695271.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	both modified:   rclpy/rclpy/executors.py
	both modified:   rclpy/rclpy/task.py
	deleted by us:   rclpy/src/rclpy/events_executor/events_executor.cpp
	deleted by us:   rclpy/src/rclpy/events_executor/events_executor.hpp
	both modified:   rclpy/test/test_executor.py
	both modified:   rclpy/test/test_task.py

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[ahcorde]

@bjsowa can you take a look to the backports?

[fujitatomoya]

i think we should close this in favor of #1560. (means we need to backport #1560)