online GeoTIFF requires some work done on service-proxy, as it currently answers with 413 Payload Too Large (obviously...)
I've tested with a Dropbox link (hence the use of the proxy). I couldn't get our STAC API to give me a file (through a URL import), it blocks somewhere (maybe on purpose, so that we don't use our STAC API as a web hosting)

instead of relying only on the file extension, will be more robust, and take into account .tif, .tiff (both as a mix of uppercased) and files without extension that are TIFF underneath

adding the new type in the layer parser
also fixing loading GeoTIFF through URL in the OL component.
removing big-endian signature check, as 99.9% of hardware on the web uses little-endian
removing the concept of GeoTIFF layer needing to load, they are either already loaded because local file, or will be loaded through the OpenLayers component (not by us, so no need to keep track of that in the menu)

and also react to changes in the source of the GeoTIFF (if the URL is changed on-the-fly)

also adding GeoTIFF to all labels linked to the file import UI (and KMZ that was forgotten)
awaiting the handleFileContent in the drag&drop handler, so that error can be caught correctly (and shown to the user)