Stopify 0.7.4

• Some dependabot updates.
• Babel parsing exceptions now handled more gracefully.

In the past, I've simultaneously bumped the versions of all the Stopify
packages. This time, I've only bumped @stopify/stopify to 0.7.4, and
all its dependencies remain at 0.7.3.

However, I am really confused about the semantics of yarn.lock.
We have a shared yarn.lock for all Stopify packages. Dependabot pushed
some updates to this file which are part of this release:

• 070d004
• 824da70
• 3ac8225
• 9edbf93
• f1f8dda

However, since it is a shared yarn.lock, I can't easily tell which of these
dependencies belong to which project. Moreover, they are mostly transitive
dependencies that we have never directly imported! So, do I need to think
more carefully and potentially publish new versions of the other packages?
Or, do I not need to think about this at all?

Stopify 0.7.3

• Polyfills for some higher-order functions that were recently added
  to JavaScript. I'm sure more remain, but these are the ones that
  were requested.
• The --require-runtime flag had stopped working, but now works again.
• GitHub's Dependabot upgraded several packages for us. Since Stopify
  is well-tested, I'm confident that they did not break anything.

Stopify 0.7.2

Merge pull request #446 from plasma-umass/version-bump

bump version

Stopify: continuations using CPS and generators

This repository has Stopify's CPS and generator based implementations of
continuations. We find that they are significantly slower than the approach
that Stopify now uses. To observe this, run the following script to time CPS
and generator based continuations:

yarn install
yarn run build
./compare.sh

The script builds and runs ./triangle.js without ever yielding. You'll find
that it is 3x (CPS) or 2x (generator) slower than compiling with Stopify
"jumper"-based strategies.

visitor-cps

First pass at propogating source locations