Set encoding as false for gulp.src to treat content as binary.

[rgrunber]

All jars passing through gulp.src are corrupted. I noticed that pre-release bulds were failing for vscode-quarkus & vscode-microprofile. When I examined the actual logs, I was seeing :

!ENTRY org.eclipse.jdt.ls.core 4 0 2024-05-02 16:27:12.411
!MESSAGE Failed to load extension bundles
!STACK 1
org.eclipse.core.runtime.CoreException: Load bundle list
    at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.loadBundles(BundleUtils.java:173)
...
...
Contains: Cannot extract bundle symbolicName or version /home/rgrunber/.vscode/extensions/redhat.vscode-microprofile-0.12.2024041608/jars/org.eclipse.lsp4mp.jdt.core.jar
java.util.zip.ZipException: zip END header not found
    at java.base/java.util.zip.ZipFile$Source.findEND(Unknown Source)
    at java.base/java.util.zip.ZipFile$Source.initCEN(Unknown Source)
    at java.base/java.util.zip.ZipFile$Source.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile$Source.get(Unknown Source)
    at java.base/java.util.zip.ZipFile$CleanableResource.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
    at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
    at java.base/java.util.jar.JarFile.<init>(Unknown Source)
    at java.base/java.util.jar.JarFile.<init>(Unknown Source)
    at java.base/java.util.jar.JarFile.<init>(Unknown Source)
    at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.getBundleInfo(BundleUtils.java:328)
    at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.loadBundles(BundleUtils.java:120)
    at org.eclipse.jdt.ls.core.internal.handlers.InitHandler.handleInitializationOptions(InitHandler.java:114)
    at org.eclipse.jdt.ls.core.internal.handlers.BaseInitHandler.initialize(BaseInitHandler.java:64)
    at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.initialize(JDTLanguageServer.java:284)

When I examined the jars, I noticed they appear to be corrupted. At first I thought it was the build process but then realized it was Gulp 5 (#196). Tracked down gulpjs/gulp#2797 and the workaround seems to work.