[api-minor] Move the viewer scripting initialization/handling into a new PDFScriptingManager class

The *main* purpose of this patch is to allow scripting to be used together with the viewer components, note the updated "simpleviewer"/"singlepageviewer" examples, in addition to the full default viewer.
Given how the scripting functionality is currently implemented in the default viewer, trying to re-use this with the standalone viewer components would be *very* hard and ideally you'd want it to work out-of-the-box.

For an initial implementation, in the default viewer, of the scripting functionality it probably made sense to simply dump all of the code in the `app.js` file, however that cannot be used with the viewer components.
To address this, the functionality is moved into a new `PDFScriptingManager` class which can thus be handled in the same way as all other viewer components (and e.g. be passed to the `BaseViewer`-implementations).

Obviously the scripting functionality needs quite a lot of data, during its initialization, and for the default viewer we want to maintain the current way of doing the lookups since that helps avoid a number of redundant API-calls.
To that end, the `PDFScriptingManager` implementation accepts (optional) factories/functions such that we can maintain the current behaviour for the default viewer. For the viewer components specifically, fallback code-paths are provided to ensure that scripting will "just work"[1].

Besides moving the viewer handling of the scripting code to its own file/class, this patch also takes the opportunity to re-factor the functionality into a number of helper methods to improve overall readability[2].
Note that it's definitely possible that the `PDFScriptingManager` class could be improved even further (e.g. for general re-use), since it's still heavily tailored to the default viewer use-case, however I believe that this patch is still a good step forward overall.

---

[1] Obviously *all* the relevant document properties might not be available in the viewer components use-case (e.g. the various URLs), but most things should work just fine.

[2] The old `PDFViewerApplication._initializeJavaScript` method, where everything was simply inlined, have over time (in my opinion) become quite large and somewhat difficult to *easily* reason about.

examples/components/singlepageviewer.js

@@ -31,8 +31,14 @@ var CMAP_URL = "../../node_modules/pdfjs-dist/cmaps/";
 var CMAP_PACKED = true;
 
 var DEFAULT_URL = "../../web/compressed.tracemonkey-pldi-09.pdf";
+// To test the AcroForm and/or scripting functionality, try e.g. this file:
+// var DEFAULT_URL = "../../test/pdfs/160F-2019.pdf";
+
 var SEARCH_FOR = ""; // try 'Mozilla';
 
+// For scripting support, note also `enableScripting` below.
+var SANDBOX_BUNDLE_SRC = "../../node_modules/pdfjs-dist/build/pdf.sandbox.js";
+
 var container = document.getElementById("viewerContainer");
 
 var eventBus = new pdfjsViewer.EventBus();
@@ -48,13 +54,22 @@ var pdfFindController = new pdfjsViewer.PDFFindController({
   linkService: pdfLinkService,
 });
 
+// (Optionally) enable scripting support.
+var pdfScriptingManager = new pdfjsViewer.PDFScriptingManager({
+  eventBus,
+  sandboxBundleSrc: SANDBOX_BUNDLE_SRC,
+});
+
 var pdfSinglePageViewer = new pdfjsViewer.PDFSinglePageViewer({
   container,
   eventBus,
   linkService: pdfLinkService,
   findController: pdfFindController,
+  scriptingManager: pdfScriptingManager,
+  enableScripting: true,
 });
 pdfLinkService.setViewer(pdfSinglePageViewer);
+pdfScriptingManager.setViewer(pdfSinglePageViewer);
 
 eventBus.on("pagesinit", function () {
   // We can use pdfSinglePageViewer now, e.g. let's change default scale.