* Fix tsconfig scopes affecting html.js
Since it's quite hard to use a DOM library type there, remove the type
entirely.
* Remove environment variables check
Nothing is using them anymore. It can be added back if needed later.
* Refactor Texture Packer downloading
Refactor local-config.js tasks file into a generic "environment"
category consisting of checking if Java is installed, downloading the
runnable Texture Packer if it's not yet downloaded and copying the local
configuration template; update README accordingly.
* Prepare environment only at postinstall
Remove environment.prepare task from default build pipelines, add a
postinstall script that calls the task, using environment.js as the
gulpfile to speed it up.
* Remove "docs" tasks and types generation script
Remove tasks from docs.js as they are unlikely to do anything meaningful
nowadays. Also remove the buildTypes script as it doesn't work anymore.
A better solution will be provided in the future.
* Simplify some globs
Use additional gulp.src options instead of specifying more or complex
globs.
* Extract built-temp location to a variable
Add the src/js/built-temp directory as a new variable in config.js,
replace all existing references to built-temp with this variable.
Building the standalone with V8 v8 (Node v14) fails at step `sounds.musicHQ`, either by running out of memory or with the error "Invalid string length". Building with V8 v7 (Node v12) succeeds.
This is because `gulp-cache` builds a 994-MB string when [stringifying file contents](https://github.com/jgable/gulp-cache/blob/master/src/task-proxy.js#L262) to cache them. V8 v8 [limits string length to around 537 MB](https://github.com/v8/v8/blob/master/src/objects/string.h#L384), and thus cannot represent this string. (V8 v7 allows around 1074 MB, which is why the build passes on Node v12.)
But [`theme-full.mp3`](https://github.com/tobspr/shapez.io/blob/master/res_raw/sounds/music/theme-full.mp3) is only 79 MB: how did we get 1250% overhead?
Unlike plaintext files, binary files are read as buffers, but [by default](https://github.com/jgable/gulp-cache/blob/master/src/index.js#L46) `gulp-cache` stringifies them naively, producing the extremely inefficient representation:
````
[
{
"cwd": "/Users/tobspr/shapez.io/gulp",
"base": "/Users/tobspr/shapez.io/res_raw/sounds/music",
"contents": {
"type": "Buffer",
"data": [
73,
68,
51,
4,
0,
0,
…etc.
````
Fortunately, `gulp-cache` [can read base64-encoded cache files](https://github.com/jgable/gulp-cache/blob/master/src/index.js#L26).
Instead of using the default file transform function, **pass a `value` option to base64-encode the file contents**. This results in only 33% overhead on cache file size (106 MB for the largest file).
This has multiple benefits:
- Fixes the build failure
- Requires less memory (from 6 GB down to < 1 GB on my machine)
- When cache files are found, the `sounds.musicHQ` is much faster (from ~30 s down to ~4 s on my machine)
- Smaller cache files on disk
