Regenerate data more often

[gsnedders]

Now we're regenerating everything from scratch on each run, including BSF, there's no reason to not regenerate everything more often. The only downside here is that we will be changing the results for the yesterday/today on multiple occasions, rather than the figures being mostly constant once they're added.

See also #80/#81 where we previously landed/reverted this. The only difference here is we run git-write.js at the start of build.sh, to make sure the local copy of the results has been updated as recently as possible. (Of course, because the various scripts call the wpt.fyi API themselves there is still a risk of a new aligned run appearing between running git-write.js and the actual scoring scripts, but that's relatively unlikely.) Ideally we'd update wpt-results-cache on demand from within each script as needed, but that's a much larger change, and also requires dealing with secrets to push to the other repo. This is almost certainly good enough for the vast majority of scheduled jobs, and even if the odd one fails we'll still have more up-to-date results than we had previously.

[gsnedders]

Oh, no, we need to change the caching of aligned runs in at least browser-specific-failures.js too.

[foolip]

Ideally we'd update wpt-results-cache on demand from within each script as needed, but that's a much larger change, and also requires dealing with secrets to push to the other repo. This is almost certainly good enough for the vast majority of scheduled jobs, and even if the odd one fails we'll still have more up-to-date results than we had previously.

Just loading the results into memory from a wptreport.json and not bothering pushing that to wpt-results-cache would avoid the secrets problem, but I agree this is good enough as-is.