Add tick event

[ffreyer]

Description

This pr adds events.tick which currently contains:

struct Tick
    state::TickState    # rendering state (paused, skipped, one-time or normal render)
    count::UInt64       # number of frames rendered 
    time::Float64       # since screen/backend event initialization
    delta_time::Float64 # between last and current frame
end

This is more verbose than just a delta time mostly because of how screen.render_tick is used in GLMakie. Updates to it are grouped with event polling since we have mouse position updates depend on it. So it triggers when

• rendering, regardless of whether a frame is rendered or reused
• rendering is paused, as not processing events would make the OS assume the program is not responding
• plot and scene insertion for the same reason (these get filtered out)
• calls to colorbuffer (i.e. save, record)

~~Depending on what causes the tick update a different state flag is passed. event_delta_time is always updated based on the time since the last tick. frame_delta_time is always based on the last renderloop event (paused/skipped/drawn) or colorbuffer event (i.e. a draw for save or record) and set to 0 when the current event is not one of those. So it's the time between the last and current frame, even if plot insertions gets between frames.~~

Currently the pr should be pretty functional, but I think we need to discuss what we want ticks to be on the user side.

• Should we ignore ticks coming from plot insertions, i.e. only include ticks related to rendering? (Which would make event_delta_time redundant) (Currently does)
• Should a paused renderloop still tick? (Currently counted)
• Should we track more data in ticks, like frame count and time-since-start as suggested in https://github.com/MakieOrg/Makie.jl/pull/3299#issuecomment-1768255595 (How should we treat reused frames with frame count? Should record reset the time-since-start?) (Currently tracking frame count, time since start, time since last frame)
• Should record overwrite the delta times in ticks to match the fps of the recording (rather than using the real time between rendered frames)? (Currently does not. My thought being that you can fairly easily use (tick.count - first_count) / fps to get the relevant delta_time.)

Supersedes #3299 Related: #3163

Type of change

• [x] New feature (non-breaking change which adds functionality)

Checklist

• [x] Added an entry in CHANGELOG.md (for new features and breaking changes)
• [x] Added or changed relevant sections in the documentation
• [x] Added unit tests for new algorithms, conversion methods, etc.
• [x] Added reference image tests for new plotting functions, recipes, visual options, etc.