Allow using builtins as higher-order functions

[hugomg]

Currently, we can call builtin functions like math.sqrt or tostring but we cannot assign them to variables, pass them to functions and so on. It raises a "not implemented" exception:

export function foo()
    local f = math.sqrt
end

lua: ./pallene/to_ir.lua:500: not implemented
stack traceback:
	[C]: in function 'error'
	./pallene/to_ir.lua:500: in method 'exp_to_value'
	./pallene/to_ir.lua:797: in method 'exp_to_assignment'
	./pallene/to_ir.lua:342: in method 'convert_stat'
	./pallene/to_ir.lua:160: in method 'convert_stats'
	./pallene/to_ir.lua:169: in method 'convert_stat'
	./pallene/to_ir.lua:149: in method 'convert_toplevel'
	./pallene/to_ir.lua:25: in function 'pallene.to_ir.convert'
	./pallene/driver.lua:73: in function 'pallene.driver.compile_internal'
	./pallene/driver.lua:103: in local 'f'
	./pallene/driver.lua:193: in function 'pallene.driver.compile'
	./pallenec:46: in local 'compile'
	./pallenec:127: in main chunk
	[C]: in ?

I think the simplest way to fix this would be to use the Lua version of these functions if they are used in a higher-order setting like this. The function objects would be stored as upvalues of the Pallene module.

• In the ir.lua, add a new variant of ir.Value which returns the function object for a given builtin name.
• In the coder.lua, create a new mapping upvalue_of_builtin, to track which upvalue slot is used for each builtin.
• In the luaopen for the Pallene module, grab the relevant builtins using lua_getglobal and store them in the appropriate upvalues.

IIRC, the reason that we haven't done this yet is because we were thinking about implementing higher-order builtins in a more efficient version than just calling the Lua implementation of them. However, not that I think a bit more about it, we can certainly leave that optimization for later.