Add support for ZIM aliases alongside redirects

[pawank925]

Add support for ZIM aliases, mirroring the existing redirect support.

• Creator.add_alias() in zim/creator: adds an alias (shares the target item content, unlike a redirect) with optional title, is_front and duplicate_ok handling, matching the add_redirect API.
• add_aliases_to_zim() in zim/filesystem: adds aliases from a list of (source, target, title) tuples and/or a zimwriterfs-compatible aliases TSV file.
• make_zim_file() exposes new aliases and aliases_file parameters.
• Deduplicator now uses the new Creator.add_alias() instead of the libzim-inherited method, so deduplicated entries get a proper title and front-article hint.

Fix #148

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (936498a) to head (4ab0081).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #355   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           42        42           
  Lines         2729      2761   +32     
  Branches       406       415    +9     
=========================================
+ Hits          2729      2761   +32     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pawank925]

@benoit74

[benoit74]

@pawank925 thank you, but this PR issue was assigned to me because it is far from clear what we wanna implement. Just added proper tag to make it more prominent. As such, I will not be able to review / merge this PR since it is far from clear what we want to do. Since this is a shared lib, we cannot introduce new API without being quite certain it is the API we want to maintain for coming years.

[pawank925]

@benoit74 thanks for the clarification Fair point You’re absolutely right about the API longevity for a shared lib.