…vious BEGIN/END/eval

… work

…ot fix race

…val boundary.

…ails console

…ome basic outline of flow in prepareFullBuild

…build race problem finally solved

…ce they test flip migrating through eval (which is currently broken and is amazing it ever worked

* Fix use of the incorrect instruction list

* Now -X-C runs with all passes again.

* Also renamed DEFAULT_COMPILER_PASSES to DEFAULT_BUILD_PASSES
  to clarify that these are passes that run for interpreter.

* Let this run on child scopes on demand so that it follows the
  new lifecycle.

* Eliminates crashers when run on closures from parent scopes.

* This can be extremely distracting in debugging output.
* Users of CFG debug output that need output from nested scopes
  should explicitly do it where required.

* No need to build full ICs for closures eagerly.

* Had to add some null checks for access to ICs in a couple
  places when I experimented turning off passes on nested scopes
  (LocalOptimizationPass, AddLocalVarLoadStoreInstructionsPass).
  Keeps that code more robust and usable in different lifecycles.

* If LVA is to run independently on closures (without parent scopes),
  it needs info about whether dyn scopes have been eliminated or not
  (see access to IRFlags.DYNSCOPE_ELIMINATED in the code).
  So, making that dependency explicit.

…ot inheriting from CompilerPass.

clonedInstrs is no longer a field in IRScope and is a local in prepareFullBuildCommon.

…een made.

…d tests for full interpreter.

…guard in LOP pass for closures

* LVA was attempting to analyze closures in the context of their
  parent scope's LVA context. The code was general enough that if
  we knew more information about specific call sites, it would have
  done better.

  However, in reality, given that we don't know too much about
  call sites, (a) all that code was extra complexity (b) it was
  really doing anything in terms of not being conservative (because
  all calls are being treated as dataflow barriers right now)
  (c) in the only case where it would not have been conservative,
  it was actually making an incorrect assumption that the closure
  will execute at the call site where it is defined and hence
  incorrectly marking a variable dead when it wasn't.

* The fix was to simply eliminate the analysis of closures in the
  context of the parent's scope. We already had support for
  independent LVA of closures which takes care of scenario (c) above
  by marking all dirtied vars live on "entry" (which in the case of
  LVA, which is a backwards pass, is the control flow exit).

  This now fixes the failing snippet (see below) and should also
  eliminate the remaining test:mri:jit failures.
[subbu@earth ir] jruby -Xjit.threshold=0 -e "z = 5; x = Hash.new {|h,kk| z = kk }; z=0; x[22]; p z"
22

Conflicts:
	core/src/main/java/org/jruby/ir/dataflow/analyses/LiveVariableNode.java
	core/src/main/java/org/jruby/ir/passes/LiveVariableAnalysis.java

…CFG before vs making on demand.

  The basic mechanics of CompilerPass on a null return will naturally run the pass on it which will
  generate the CFG on demand along with the data.
Add comment in getCFG explaining when fic will be null.
Comment out child closure passing from LOP because we don't want it but left it comments out because
  it exposes some lifecycle problems.  Once we stabilize hypernugget and merge back to master we
  will dig into this problem more.

…ablesProblem.

Remove DataFlowConstants since it was already mostly dead.
Hook up more LVP getters to reduce externalized use of FIC.

…ation of FIC.

…ences in IRScope now.