Allow specifying the `PDFJS_NEXT` build flag via an environment variable when running the various `gulp` commands
Allow specifying the `PDFJS_NEXT` build flag via an environment variable when running the various `gulp` commands

After PR 8459, the run-time of the various `gulp` test commands has regressed quite badly on Windows. For me, `gulp test` now takes approximately *twice* as long when run locally on Windows.
The problem seems to be the Babel transpilation step, which takes well over five minutes to run.[1]

For someone like me, who runs tests a lot locally, this slowdown is really hurting the overall development experience.
To get around this I tested setting `PDFJS_NEXT = true` in `gulpfile.js`, since the transpilation step isn't necessary when testing in a modern browser.

However, having to edit `gulpfile.js` every time that I need to run tests isn't very practical. Hence this patch, which adds an environment variable that allows you to disable the transpilation simply by using e.g. `PDFJS_NEXT=true gulp test`.

I hope that this can be considered an acceptable solution, such that I don't need to maintain this patch locally (or worse, edit `gulpfile.js` locally before testing).

---
[1] This can also be observed on the Windows bot, but it seems fine on Linux.

mainegreen/pdf.js,macroplant/pdf.js,Snuffleupagus/pdf.js,mukulmishra18/pdf.js,mainegreen/pdf.js,mozilla/pdf.js,Shoobx/pdf.js,caremerge/pdf.js,skalnik/pdf.js,mozilla/pdf.js,nawawi/pdf.js,Snuffleupagus/pdf.js,adlerweb/pdf.js-Touch,Rob--W/pdf.js,Shoobx/pdf.js,macroplant/pdf.js,mukulmishra18/pdf.js,nawawi/pdf.js,mozilla/pdf.js,nawawi/pdf.js,showpad/mozilla-pdf.js,macroplant/pdf.js,skalnik/pdf.js,caremerge/pdf.js,adlerweb/pdf.js-Touch,Snuffleupagus/pdf.js,timvandermeij/pdf.js,showpad/mozilla-pdf.js,xavier114fch/pdf.js,Rob--W/pdf.js,timvandermeij/pdf.js,websirnik/pdf.js,timvandermeij/pdf.js,showpad/mozilla-pdf.js,websirnik/pdf.js,xavier114fch/pdf.js,Shoobx/pdf.js