Again, correct the context of `_` within `meteor shell`.
Again, correct the context of `_` within `meteor shell`.

A truthy `useGlobal` option when calling Node's `repl.start()` will use
the `global` context, which will allow global Meteor variables (such as
the global `_` provided by the `underscore`) to be available in the context
of the REPL shell.  This sounds desirable, and in fact, the original
implementation set it as such, only to be later changed to `false` in
https://github.com/meteor/meteor/commit/7c7e52f2d2, specifically to
avoid the undesirable behavior of Node REPL stomping on the global `_`
variable with its own special-meaning `_` variable which is set to the
value of the most recently eval'd expression.

This was once again changed to `true` to fix the lost tab-completion
functionality, thanks to https://github.com/meteor/meteor/commit/2443d83226,
which also implelented special mutator on `_` to avoid breaking
it.  As it's probably clear now, this has been a struggle, and because
of Node using its own `Object.defineProperty('_', ...)` as of Node.js 6
(in https://github.com/nodejs/node/pull/5535/files), this problem has
surfaced again, as reported in https://github.com/meteor/meteor/issues/9276.

This changes the behavior to another implementation which starts with
`useGlobal` set to `false`, but then sets the context immediately to
`global`, which seems to avoid the problem.

It's possible that another option might be to set explicitly set the
`underscoreAssigned` attribute on the `repl` after starting it, however
since that's an internal, undocumented property, it might be best to avoid.

This does maintain the existing behavior of our special
double-underscore variable, in order to get the value of the last
REPL expression, in the same manner as `_` would in a normal REPL, by
accessing the internal `last` property.  Since this is also undocumented
(on our end), this seemed reasonable.

Hansoft/meteor,Hansoft/meteor,Hansoft/meteor,Hansoft/meteor,Hansoft/meteor,Hansoft/meteor,Hansoft/meteor