support --diff-ignore-mode flag to ignore differences to file mode

[G-Rath]

Pretty much exactly what's in the title: it would be nice if npm diff supported ignoring differences in file mode via a flag like --diff-ignore-mode.

This can be useful when you're working on file systems whose permissions systems are "virtual" - specifically in my case WSLv1, where files on the Windows FS usually end up with a file mode of 777.

For example currently I commonly get this sort of output when using npm diff:

❯ npm diff --diff @types/node@14.14.36
diff --git a/LICENSE b/LICENSE
old mode 100755
new mode 100777
index v14.14.37..v14.14.36
--- a/LICENSE
+++ b/LICENSE
diff --git a/README.md b/README.md
old mode 100755
new mode 100777
index v14.14.37..v14.14.36
--- a/README.md
+++ b/README.md
@@ -8,7 +8,7 @@
 Files were exported from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node.

 ### Additional Details
- * Last updated: Sat, 27 Mar 2021 00:01:17 GMT
+ * Last updated: Thu, 25 Mar 2021 18:01:17 GMT
  * Dependencies: none
  * Global values: `Buffer`, `__dirname`, `__filename`, `clearImmediate`, `clearInterval`, `clearTimeout`, `console`, `exports`, `global`, `module`, `process`, `queueMicrotask`, `require`, `setImmediate`, `setInterval`, `setTimeout`

diff --git a/assert.d.ts b/assert.d.ts
old mode 100755
new mode 100777
index v14.14.37..v14.14.36
--- a/assert.d.ts
+++ b/assert.d.ts
diff --git a/async_hooks.d.ts b/async_hooks.d.ts
old mode 100755
new mode 100777
index v14.14.37..v14.14.36
--- a/async_hooks.d.ts
+++ b/async_hooks.d.ts
@@ -151,7 +151,7 @@
         /**
          * Call AsyncHooks destroy callbacks.
          */
-        emitDestroy(): this;
+        emitDestroy(): void;

         /**
          * @return the unique ID assigned to this AsyncResource instance.
diff --git a/base.d.ts b/base.d.ts
old mode 100755
new mode 100777
.... (~10-20 more files worth of "old mode, new mode") ...

(I actually suspect there might be a bug somewhere, as when inspecting the files the modes still don't quite line up with what I'd expect but I think this flag will still be useful for people).

I'm happy to help work on implementing this and doing an RFC if required.