Feature: Remember, save, and load highlights across slides

[NattXCZ]

This Pull Request introduces a new functionality to remember, save, and load drawings (highlights) across presentation slides. Previously, the application only offered basic drawing capabilities where strokes were automatically cleared upon transitioning to another slide, without any option to keep them.

• Drawings are saved to and loaded from a .pdf.json file located in the same directory as the presentation.
• The previous implementation drew strokes into the Cairo cache (scribble_cache), which required regeneration every time the window was resized. The new version stores all data as normalized vectors.
• Added an "Exit highlight on page change" option that automatically exits the drawing mode when switching to a different slide

Available Modes:

• Clear on page change (single-page): Keeps the original behavior where all drawings are erased when moving to another slide.
• Never clear / manually only (global): Drawings remain visible across all slides and must be cleared manually.
• Clear and restore per page number (per-page): Each slide maintains its own set of drawings, identified and restored based on its sequence number.
• Clear and restore per page label (per-label): Functions similarly to the per-page mode, but uses the slide's text label as the key.

Technical Details:

• document.py: Added the scribble_data_path method to locate the path to the save file.
• scribble.py: Implemented methods for reading and writing the JSON file. This includes the use of a temporary file to prevent data loss during saving.
• ui.py: Added calls to these save/load methods during slide changes and document open/close events.
• Data Structure Update: Replaced the original remembered_scribbles data structure with a per page structure that is used across all drawing modes. The key for this structure is either an integer slide index (for global and per-page modes) or a label (for per-label mode).

[Cimbali]

Hmmm I always wanted the highlighting to be saved in the pdf as annotations rather than a separate file. But that might not be the most reasonable (I think it's not doable with the popper api atm). This is a useful enough feature I think that a clean implementation of a semi-readable file next to the pdf could be acceptable.