Prevent regeneratorRuntime is not defined errors by defensively copying targets (preventing @babel/helper-compilation-targets from mutating targets)

[fivetanley]

Babel 7.10.0 introduced a change that mutates the targets object passed into @babel/helper-compilation-targets. Since ember-cli caches the value of config/targets.js on the Project,
that means any subsequent calls to ember-cli-babel would lose @babel/preset-env options defined in targets if the ember-cli babel was
included again anywhere else in the tree (which it usually is due to addons depending on ember-cli-babel). This would sometimes result in a regeneratorRuntime is not defined error for addons like Ember Concurrency that use ECMAScript features like generator functions or async functions, because the addon would not be compiled against the appropriate browsers list (or other @babel/preset-env options) because @babel/helper-compilation-targets mutated it away. This would happen usually in development or test, if limiting the targets used in development , which has been the default in Ember CLI for a while now. regenerator was not included in the host app because it was using the appropriate browserlist, and so ember-maybe-import-regenerator did not include regenerator runtime in the build. Ember concurrency then would get compiled without the appropriate targets, and would get compiled down to IE9/regenerator runtime instead of using native generator/async await syntax.

As a workaround, we can copy the targets object before passing it to @babel/helper-compilation-targets as a workaround until the regression is fixed upstream in babel.

The yarn.lock changes were made to bring in babel 7.10.0 so we could test this change.

[rwjblue]

Thank you again @fivetanley!