ndk: Use BorrowedFd and OwnedFd to clarify ownership transitions

[MarijnS95]

Depends on #416

Some functions consume a file descriptor (will close them on their own regard) or return ownership over a file descriptor (expect the caller to close it), but this is not always clarified in the documentation nor upheld by the caller. Use the new stabilized BorrowedFd and OwnedFd types since Rust 1.63 to clarify this in the API, noting that OwnedFd will instinctively close() the file descriptor on drop and doesn't implement Copy nor Clone (but does provide a try_clone() helper using fcntl() to create a new owned file descriptor if needed, and if possible by the kernel).

For example, while not obvious from AHardwareBuffer_lock() docs (though there are hints in the graphics sync docs) the source for gralloc buffer locking many function calls down clarifies that the acquireFence is indeed owned and will be closed. The same applies to AImageReader and its async aquire functions.

[MarijnS95]

I will think about this a bit more before merging (cc @rib).

This is an fd the user gave to us (as a BorrowedFd, though) so they're already required to make sure it isn't closed until it is removed from the Looper. Second, as written above the unsafe block that creates this:

                // SAFETY: Even though this FD at least shouldn't outlive self, a user could have
                // closed it after calling add_fd or add_fd_with_callback.

There's barely any relevance to self here; the user can totally keep using their own fd outside the scope of Looper, we really have no clue what its lifetime should be.

Most importantly, let's check if winit can easily handle the lifetime that we've now added to Poll<'fd>.

[MarijnS95]

Turns out I made the biggest mistake I could here: by calling as_raw_fd() on an OwnedFd we're merely borrowing the OwnedFd, meaning it gets dropped by us at the end of the Rust function rather than "transferring" ownership to the FFI function, meaning close() ends up being called twice.

Converted this PR to draft for that as I want to test out the new codepaths first before merging this... and while setting up a test-case I ran into more lifetime/reference issues in the NDK 😩. Release will probably be bleeding into next week.

[MarijnS95]

I managed to test the lock() ownership transition with an ImageReader where I use its producer end (the NativeWindow that we refcounted wrongly, #418) in EGL: this lets the ImageReader return a SyncFence (blocking on GL GPU completion) file descriptor when asynchronously acquiring the latest Image, which can subsequently be used to .lock() the HardwareBuffer inside the Image. I tested the ownership transitions here with some libc::close() (since the drop() for OwnedFd discards the error) and confirmed that the NDK closes it for us.