🏗 Cache Karma's babel transforms during CircleCI builds

[rsimha]

AMP's Karma tests persist their babel transforms in .karma-cache (#28157). We lost the ability to cache the directory on Travis due to #28834 (comment). This PR reintroduces caching for the directory on CircleCI.

Results are great. We shave off ~30 secs from integration test runs, and ~5 mins from unit test runs.

Cold cache:

Warm cache:

Coming up: Caching for babel transforms in end-to-end tests. (Edit: Doesn't save more than a few seconds, so not worth it.)

[samouri]

🔥

[rsimha]

Question for you, @jridgewell. As things stand today, CircleCI uses a hash of package-lock.json as its cache key. This means it won't rewrite the cache if the lockfile hasn't changed (e.g. last step of this build).

However, we've configured browserify-persist-fs to bust the cache and re-transform all files when there's a change in either package-lock.json or a bunch of files in build-system.

amphtml/build-system/common/browserify-cache.js

Lines 34 to 43 in e9e76fd

	const hashObject = {
	deps: createHash(fs.readFileSync('./package-lock.json')),
	build: globby
	.sync([
	'build-system/**/*.js',
	'!build-system/eslint-rules',
	'!**/test/**',
	])
	.map((f) => createHash(fs.readFileSync(f))),
	};

This means if build-system changes but package-lock.json doesn't, unit tests will remain slow on CircleCI until the next change to package-lock.json. CircleCI docs don't seem to show a way to use globs to generate the cache key. Can you think of a workaround to optimize this further?