Add a way to easily convert an AndroidAppWaker into a Waker

[notgull]

This commit adds a "waker()" method to AndroidAppWaker. It converts it
into an std::task::Waker, which is the type of waker used by
asynchronous tasks for scheduling. The goal is to allow AndroidAppWaker
to be easily used to set up an asynchronous context.

The implementation is very efficient, owing to the "static pointer"
style of coding already used. The "wake" function just calls
ALooper_wake, and cloning/dropping the waker is just a copy.

Discussion questions:

• Should waker() take &self or self? I chose the latter.

[notgull]

Build failure is due to codebase rot

[MarijnS95]

#164 (comment)

Yeah, we're really lacking maintenance here, unfortunately. As always, I'm happy to submit PRs to tackle issues and implement features every once in a while in between other tasks, but need a second maintainer for review and approval.

@rib can you update us on your availability and commitment towards this crate, or should we seek for a third maintainer to fill this review-gap?

[MarijnS95]

Regarding the PR itself, note that the result of a looper wake is very loosely defined and not to be relied on: #170

If there's any explicit async task spawning and progress monitoring that needs to happen on an ALooper, I'd prefer if we add an abstraction based on file descriptors or callbacks which, unlike waking, can be explicitly handled.

[notgull]

Interesting. Does it have a chance of spuriously not waking up the event loop? winit currently assumes it always does.

[MarijnS95]

@notgull according to their documentation, it would get batched up with other events, such that the event loop is "active" / "awake" but without ever seeing it return WAKE because it got "folded into" the other events.

winit currently relies on Poll::Wake to trigger a user-requested redraw:

https://github.com/rust-windowing/winit/blob/ae4c449670674d8ac0d6d8754caf3fe5f4954c25/src/platform_impl/android/mod.rs#L586-L602

But it also checked these before entering a poll_events(): https://github.com/rust-windowing/winit/blob/ae4c449670674d8ac0d6d8754caf3fe5f4954c25/src/platform_impl/android/mod.rs#L562-L565

With these findings, it'll miss events on redraw_flag and proxy_wake_up, unless we hoist those checks out of the match block for any Poll/Err returned out of poll_events(). Or if we want to be more specific, attach a pipe or eventfd to be guaranteed a consistent result whenever our channel into the Looper signaled anything.

[notgull]

I would prefer to just use eventfd.

[MarijnS95]

Same preference here, it's much more explicit than pretending every Poll could have a Wake folded into it.

For redraws specifically, there's a preference to handle these via AChoreographer intead, which would bump the API requirements. But that's for a future discussion.