Consider eliminating cur_L

[corsix]

(Split off from #1066 (comment))

The introduction of cur_L in 517500b had this to say:

Save currently executing lua_State in g->cur_L.

This is only a good approximation due to deficiencies in the design of the Lua/C API. It indicates some valid state that is/was executing.

The current usages of cur_L within the LuaJIT codebase are:

• JIT-compiled code loads from cur_L whenever it needs a lua_State* (e.g. to call a function that might allocate memory) (except for ARM32 backend, where loading from G on-trace is not pretty, so it'll load cur_L at the head of a trace, and then spill it to its own stack if required).
• JIT-compiled code can call lj_gc_step_jit, which loads from cur_L to determine the lua_State* (this seems marginal; it might be just as easy for traces to pass L as it is to pass G).
• lj_state_shrinkstack (called during GC, which is sometimes on-trace) uses cur_L to avoid shrinking the stack of the live trace (it could instead check tvref(G(L)->jit_base) != L->base).
• When leaving JIT-compiled code, lj_vm_exit_handler loads from cur_L to recover the lua_State*.

All of the above could load from tmpbuf.L instead of cur_L (or could load from the ambient cframe's SAVE_L, but this is only really interesting for ARM32). Merging cur_L into tmpbuf.L could get rid of some stores (either stores to cur_L when entering the VM, or stores to tmpbuf.L when transitioning from the VM to a trace and stores to tmpbuf.L in lj_buf_tmp / lj_buf_tmp_).

The only unknown is usage of cur_L outside the LuaJIT codebase; @MikePall says:

AFAIR there are third-party tools that try to traverse the Lua stack while a trace is running and they rely on cur_L. They need some replacement functionality. LuaJIT really ought to provide documented and reliable functions for extended VM introspection and debugging.