Make compressing transforms cache configurable

[thymikee]

Please check if the PR fulfills these requirements

• Tests for the changes have been added
• Docs have been updated

What kind of change does this PR introduce?

• Feature

What is the current behavior?
Cache compression is mandatory

What is the new behavior?
One can opt out from compressing cache using the new cacheCompression: boolean option.
By default set to true so it doesn't break anything.

Does this PR introduce a breaking change?

• No

• Impact: couple % faster builds for large projects (1k+ transpiled files)
• Github Issue(s) this is regarding: Resolves What's the idea behind compressing cached output #571

Other information:
I wrote a bit about in related issue #571

[danez]

The question we still have is if we maybe remove the cache alltogether and instead recommend using cache-loader.

Have you tried using cache-loader in front of babel-loader that should be faster than the babel cache.

[thymikee]

@danez, I didn't try it yet, but I'll try to got to that soon. I've heard Webpack 5 is going to focus on better build cache system – I wonder what are the ideas for caching transformers like Babel or TS with sourcemaps, also for cache-loader.

BTW, I have another branch locally where I split code from maps and save both to FS (if necessary) – this way only maps need to be serialized, code goes straight to the disk. The wins are only visible for inline source maps (~5-10% IIRC) though, otherwise it performs similar, so I'm not so happy about that.

I'll yet have to profile the code properly using --inspect to be sure what's slowing things down instead of guessing 😅.

[loganfsmyth]

I rebased your branch over our new async-function implementation, and made 2 small changes:

• Use the name cacheCompression in the cache function options too
• Move the filename .gz-injection logic to the read/write functions.

[loganfsmyth]

Thanks!