[Firefox] Don't send the "abortLoading" message synchronously

Despite the comment, I believe that changing this should be fine for two separate reasons:
 - The platform code has an "unload" event listener, see [this code](https://searchfox.org/mozilla-central/rev/edb2612db13e89f1c44ab95b1e4d4366c16eb9fb/toolkit/components/pdfjs/content/PdfStreamConverter.sys.mjs#533-538), that invokes the same method. Hence we should still be guaranteed that the relevant platform method will run.

 - The `FirefoxComDataRangeTransport.abort` method is never actually invoked in the Firefox PDF Viewer.
   Note that the [`PDFDataRangeTransport.abort` method](f4b396f6c8/src/display/api.js (L759)) is only invoked via the [`PDFDataTransportStream.cancelAllRequests` method](f4b396f6c8/src/display/transport_stream.js (L167-L175)), which in turn is only invoked via the [`WorkerTransport.destroy` method](f4b396f6c8/src/display/api.js (L2485-L2487)). That method is invoked via the [`PDFDocumentLoadingTask.destroy` method](f4b396f6c8/src/display/api.js (L630)), which in the viewer is only invoked via the [`PDFViewerApplication.close` method](f4b396f6c8/web/app.js (L919)) which is never actually called in the Firefox PDF Viewer.

All-in-all, given the existing platform code *and* the current viewer-implementation it should thus be safe to not wait for the "abortLoading" message to complete.

web/firefoxcom.js

@@ -314,9 +314,9 @@ class FirefoxComDataRangeTransport extends PDFDataRangeTransport {
     FirefoxCom.request("requestDataRange", { begin, end });
   }
 
+  // NOTE: This method is currently not invoked in the Firefox PDF Viewer.
   abort() {
-    // Sync call to ensure abort is really started.
-    FirefoxCom.requestSync("abortLoading", null);
+    FirefoxCom.request("abortLoading", null);
   }
 }