Stop using `--no-lockfile` / `--no-shrinkwrap` by default? 🤔 about ember-try

[mansona]

I've just come across this issue and I think I strongly agree with @rwjblue on this 🤔 I'm in the process of trying to remove deprecations from my addons ahead of the 4.0 release and I've been noticing really strange and surprising behaviour when trying to add tests for deprecations.

I think most devs would expect that only the dependency that is specified in the ember-try scenario would change and everything else would remain locked. I know it's very clear in the README but that doesn't mean that it isn't surprising to a lot of people 😂

This is partially responding to #598 (comment)

[ginomiglio]

I agree with this as well.

I also want to point out that given events like veged/coa#99, --no-lockfile is a bit of a security issue too. A compromised package that is quickly discovered by the maintainer has a low risk of making it into most people's builds, but ignoring the lockfile makes it more likely that the bad version is downloaded and run by a CI job before it can be removed.

[rwjblue]

Note: this proposal would require adding npmOptions to the list of possible fields in the scenario, so that they can be modified / overriden at each scenario level.