[FEATURE]: Add Snap packaging support with Github workflow

[x15sr71]

In raising this pull request, I confirm the following:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the changelog.

My familiarity with the project:

• I am an active contributor to CCExtractor.

---

Summary

As proposed in #1583, this PR adds Snapcraft-based packaging for CCExtractor, along with a GitHub Actions workflow that builds the Snap and uploads the resulting .snap artifact to GitHub Releases.

Benefits:

• Cross-distribution Linux support
• Self-contained runtime dependencies
• No impact on existing build systems or packaging flows

---

Implementation Details

• snap/snapcraft.yaml
  Snapcraft configuration using the existing CMake build system. Runtime dependencies (FFmpeg, GPAC, Tesseract, etc.) are bundled explicitly via stage-packages.

• snap/local/run-ccextractor.sh
  Lightweight runtime wrapper that ensures bundled shared libraries are resolved from within the Snap at execution time, avoiding accidental linkage against host system libraries. While the Snap may work without this wrapper on some environments, it makes runtime behavior deterministic and consistent across distributions.

• .github/workflows/build_snap.yml
  GitHub Actions workflow completes successfully and produces a .snap package, which is published as a CI artifact (zipped by GitHub Actions).

---

Testing

• GitHub Actions workflow completes successfully and produces a .snap package
  (CI run artifact).

• Local runtime verification performed on:

  • Ubuntu 22.04 (Jammy)
  • Ubuntu 24.04 (Noble)

   sudo snap install ./ccextractor_*.snap --classic --dangerous
   ccextractor --version

• The release-triggered workflow uses the same job definition and artifact upload logic as the manually verified CI run, so the generated .snap artifact should be attached to GitHub Releases as well.