fix(api-base): resolve resource promises in parallel

[thoughtpolice]

Summary: When fetching built-in resources (e.g. techlibs) for the virtual filesystem, do it in parallel by building up an array of promises and resolving them via Promise.all, rather than doing so sequentially.

A nice effect of this is that it helps avoid HOL blocking when the resource might be non-local e.g. your in-browser HTTP request to a CDN or server suddenly starts having bad latency.

It also lets us get away with less logging (ref: #2), and removing these explicit console.log calls actually fixes an awkward case where printLine is set to a no-op function to keep things quiet, but these logs would still get output with no way to suppress it. (If this is ever brought back it should at least respect the printLine callback.)

Fixes #2.

Change-Id: Ie8085a216c22576d6956f007e2859e2381a56a12

[thoughtpolice]

I ran the testsuite, so I hope this is OK, but please keep my baby JavaScript skills in mind.

[whitequark]

(If this is ever brought back it should at least respect the printLine callback.)

The package is primarily targeting the browser use case, where console.log is invisible. I agree that expanding its scope to Node/Deno is reasonable, and dropping these calls to console.log is also reasonable. I see no need to forward this information to printLine; that exists solely for the application itself, not for any debug information, since the embedder may want to interpret that info.

[whitequark]

Note that once this is merged, all packages will need to (a) have the version bumped in package.json and (b) be re-published, since they bundle the runtime.

[whitequark]

Thanks!

[thoughtpolice]

Thanks for the quick response! Much appreciated.