Offline mode in mobile interface (only WMTS layers)

Description

Allow to download WMTS Tiles for offline usage in the mobile interface.

Job done

• Added a Service Worker to manage offline fetch calls
• Added an OfflineManager class to allow downloading WMTS tiles
• Added an Offline component to indicate to the user when he is offline
• Added some config for offline in the config file
• Do some linting on other classes. (I don't really understand why we had those errors, they should have been detected during the build...)
• Add doc for offline configuration: https://doc.geomapfish.dev/docs/configuration/#offline

Use-Case / Testing

• The application must be started twice to allow the Service-Worker to be installed correctly (Service Workers are only fully installed once you firt leave the application)
• Then, if you zoom a bit deeper in the map, a button will appear. It allow you to download all the active WMTS layers for an offline usage.
• A progress bar at the bottom of the mobile interface will show you the download progress
• When everything has been downloaded, you can go offline (For tests, offline mode can be activated in the dev tools, in the tab application)
• If you go offline, an icon wil appear on the map, showing that you are offline, and a red square will show you which areas were downloaded for offline use.
• You can zoom to those areas, the tiles will be loaded from cache.
• In offline mode, you can also refresh the whole app (F5), because the application itself is also cached.
• If you go online again, everything will work noramally again.

This has only be integrated on the mobile interface.
This works with mobile and in the APK.

Definition of Done

For the Developer:

• Code compiles and conforms to defined coding standards (eslint, tsc, prettier).
• If necessary (at the developer's discretion), unit tests have been added for critical parts.
• All unittests run without error.
• Sonar-Scan returns no new issues or security hotspots.
• Documentation has been updated where necessary (see documentation repository).
• Merge-Request contains a few explanations of what was done.
• A Reviewer has been assigned to the Merge-Request.

For the Reviewer:

• New code was reviewed.
• If comments could be added on unclear code, the developer has been informed.
• If unitests could be added in certain places, the developer has been informed.
• Merge-Request was merged on main branch.
• All pipelines work.
• The changes were tested on demo environment.
• Application performance has not been degraded by the modifications.