Zero-copying on Android

[madsmtm]

There's a few things that make zero-copying difficult on Android:

• Buffers are in RGBX format instead of BGRX. Should be fixed by github.com/Add Pixel struct and PixelFormat enum #289.
• Buffers have stride. Should be fixed by Add Buffer::byte_stride and use it on Android #315.
• Buffers are exposed as &mut [MaybeUninit<u8>], see NativeWindowBufferLockGuard::bytes. Is this really necessary, or could we rely on the buffer being zero-initialized? If not, we'll have to do a zeroing step ourselves in buffer_mut.
• The surface is both unlocked and presented in NativeWindowBufferLockGuard::drop, whereas Softbuffer allows these two steps to be separate (e.g. you can Drop an in-progress Buffer<'_> and request a new one in Surface::buffer_mut, with no side-effects).

Maybe the SurfaceControl stuff @MarijnS95 is working on will allow fixing the last point?

[MarijnS95]

For the last point: I'm curious what happens if lock() is called twice without unlock(); i.e. dropping the buffer while forgetting to present it, if drop() -> unlock() didn't do both automatically. It may seem the Android API doesn't allow this.

That branch surely solves it, but has high Android requirements (most API was added in 29, but a bugfix to use it on the root NativeWindow surface only got accepted in 35). I'll open a PR either way to discuss the details and not forget about it.

[MarijnS95]

What happens if I std::mem::forget(buffer) in place of buffer.present(), the second lock()` fails:

Surface : Surface::lock failed, already locked
RustPanic on Os { code: 38, kind: Unsupported, message: "Function not implemented" }