Canvas interactivity and Game of Life example

[hecrj]

This PR adds interactivity support for the Canvas widget and simplifies its API.

A Canvas is now created with a value implementing the new Program trait. A Program contains the local state of the Canvas, describes its update and draw logic, and can produce meaningful messages.

The Layer and Drawable traits have been removed as they added an unnecessary level of indirection to the drawing API. Drawing now consists in directly generating a bunch of Geometry with a Frame or Cache in the Program::draw method. Users should be able to create any further drawing abstractions on top of this API to satisfy specific use cases.

The changes to the canvas API triggered a bunch of refactors and internal improvements, affecting a considerable part of the codebase. Specifically:

• Additional convenient methods and traits have been implemented for Rectangle, Point, Vector, and Stroke.
• The mouse types of iced_native have been moved to iced_core.
• A new primitive Translate was added to iced_wgpu.
• The Mesh2D primitive has now a size field and any geometry that falls out of bounds is clipped.
• MouseCursor has been renamed to mouse::Interaction with a new Crosshair variant.
• The Input variant in keyboard::Event and mouse::Event has been split into explicit pressed and released variants.
• A new time module has been created, which is only exposed when either the tokio or async-std features are enabled. This module currently only exposes an every function that returns a Subscription that produces messages at a set interval. This simplifies some examples considerably!
• The bezier_tool example has been updated to also use a Canvas widget instead of a custom one.

As always, I have implemented a new example to showcase the new features. The new game_of_life example implements an interactive version of Conway's Game of Life on top of the new canvas API!

[hecrj]

@clarkmoody I have implemented cursor-based zooming and increased the speed limit to 100:

Serious lag when drawing at speed > 500

The lag is somewhat expected as the tick strategy is very naive for simplicity's sake. If the simulation logic can't keep up with the tick rate, ticks will accumulate and eventually hang the application.

Mouse interaction not detected when drawing at high frame rate

If the tick rate is higher than the refresh rate of your monitor, there are states of the simulation you will not see. New cells will also immediately die after drawing them, given the rules of the game.

[clarkmoody]

Excellent! Tested and works at e7e8e76

[hecrj]

I have made the simulation run in a background thread and also implemented some logic to avoid ticks from accumulating. The GUI now will stay responsive even if the simulation cannot keep up with the requested tick rate!

Additionally, I have:

• Added a grid checkbox, which will enable grid lines if checked.
• Included some tick statistics in an overlay at the bottom-right corner (amount of cells, average tick time, and amount of queued ticks).
• Implemented an "erase interaction". Simply click on an already populated cell to start erasing!
• Replaced the default hasher with rustc_hash.

I am pretty happy with this example and I believe we are ready to merge! 🎉