Measure performance impact of recent async changes

While getting ready for Meteor 3.0, we've done a lot of internal changes (#412, #413, #424, #428; soon also one for #443). Most of them are simply adding on top of the existing logic to support `Promise`s virtually _everywhere_; some are actual redesigns (e.g., shape of `_scopeBindings`).

Of course, adding more logic always comes with a cost, and we should check, whether it's acceptable. So far we didn't hear about any visible regressions, but it should be checked nevertheless.

It's strongly connected to #383, since the majority of the benchmarks should remain synchronous-only, so we could compare the results with previous versions.