Add Buffer::present_with_damage() and Buffer::age()

[ids1024]

#39.

Implemented only for Wayland. Should be able to add an X implementation using XDamage, but I haven't looked at how that works yet. On web we could use this to update only the changed part of the canvas possibly. If we need to convert the format anyway. I don't see any API for damage that could be used on macOS or Windows.

Also should be tested in some way.

[ids1024]

https://www.x.org/releases/X11R7.7/doc/damageproto/damageproto.txt

Damage is automatically computed by the X Server for X rendering operations,
but direct rendering extensions have allowed clients to perform rendering
outside of the control of the X Server. The 1.1 version of the protocol
added a request to allow direct rendering clients to report damage to a
drawable.

If we're using put_image/shm_put_image, we're not doing "direct rendering" (like a DRI based OpenGL client), and those calls already report damage to region we "put" to? And I don't see a way to disable that damage reporting.

So I guess on X, we'd not use XDamage here, but could call put_image/shm_put_image once per damage rectangle, with different src_x/src_y/dest_x/dest_y/width/height arguments?

[ids1024]

Yep, iterating over rects and calling X11_XShmPutImage or X11_XPutImage is what SDL's X11_UpdateWindowFramebuffer does.

Now to look at how https://wiki.libsdl.org/SDL2/SDL_UpdateWindowSurfaceRects is implemented in other backends to see if it can be done elsewhere...

Edit: Ah, WIN_UpdateWindowFramebuffer calls BitBlt for each rect. So we can do the same easily enough.

[ids1024]

Everything here should work now, but is untested.

[ids1024]

Updated to use u32/NonZeroU32 and return an error for out-of-range damage rects. It also now panics on present if resize wasn't called on X11 and Windows now, though we may want to require an initial window size instead (#106).

Still not properly tested, but there shouldn't be much that could go wrong here, and merging would help us work on other things without accumulating more conflicts. I still need to see about making use of both of these features in Iced's new software renderer.

[ids1024]

Updated to address conflicts with #104.

[notgull]

Looks good to me!

[ids1024]

I think we can merge this now. So more backend code changes can be made without adding conflicts. If any issues come up later, they can be fixed.