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.

gulpfile.js

@@ -131,6 +131,8 @@ function createWebpackConfig(defines, output) {
   var licenseHeader = fs.readFileSync('./src/license_header.js').toString();
   var enableSourceMaps = !bundleDefines.FIREFOX && !bundleDefines.MOZCENTRAL &&
                          !bundleDefines.CHROME;
+  var pdfjsNext = bundleDefines.PDFJS_NEXT ||
+                  process.env['PDFJS_NEXT'] === 'true';
 
   return {
     output: output,
@@ -152,7 +154,7 @@ function createWebpackConfig(defines, output) {
           loader: 'babel-loader',
           exclude: /src\/core\/(glyphlist|unicode)/, // babel is too slow
           options: {
-            presets: bundleDefines.PDFJS_NEXT ? undefined : ['es2015'],
+            presets: pdfjsNext ? undefined : ['es2015'],
             plugins: ['transform-es2015-modules-commonjs']
           }
         },