v2: `space-lua`: Implement `select(index, ...)` and align behaviour of the `#` operator with Lua 5.4

[mjf]

The Lua implementation is missing the select(index, ...) [1] function...

${select(1, "a", "b", "c")}

should yield: a but it instead yields and error: "Lua error: Attempting to call nil as a function".

It's very limiting issue because without the select(index, ...) functions like the following one simply cannot be implemented (not tested in SB, works in normal Lua)...

function coalesce(...)
  local argn = select('#', ...)

  if argn == 0 then
    return nil
  end

  local argv = { ... }

  for i = 1, argn do
    if argv[i] ~= nil then
      return argv[i]
    end
  end

  return nil
end

---

Note: The select(index, ...) is the most performant and often used way to get number of variadic arguments of a function: select('#', ...). Therefor it should not be (and, in fact, it cannot be) implemented as interpreted in the Lua itself but rather be part of the embedded Lua core, similarly to the other core Lua functions. The select(index, ...) even cannot be implemented in interpreted Lua because the # operator and similar may have some special properties (e.g., the #{...} stops counting on nil values etc.). So the only way to iterate properly over ... incuding nil values is the select(index, ...) function. I ask for implementing the select(index, ...) directly in the core of the Lua interpreter because it's rather part of the language syntax than anything else.

[mjf]

I dug more deep into it and realized that in space-lua the #{...} returns correct number of arguments by counting nils properly... which is not aligned with Lua 5.4 interpreter.

```space-lua
function argn(...)
  return #{...}
end
```
${argn()} ${argn(nil)} ${argn(nil, nil, nil)} ${argn(nil, 1, nil)}

The above returns indeed the (un)expected

0 1 3 3

In Lua 5.4 the above argn(...) returns weird results (at least at first glance, but see below). But if I replace the #{...} with select('#', ...) in the function above, it works as expected. All that mean that there is major misalignment between the Lua 5.4 interpreter and space-lua interpreter. Therefor I would still beg for providing the select(index, ...) that will be Lua 5.4 compatible and aligning the way the # operator works (see below), or at least document that the behaviour of the # operator is very different (the worse scenario because it's very unexpected behaviour). I consider both missing select(index, ...) and misbehaving # operator to be bugs myself and crutial to fix (as soon as possible, before all the new space-lua code people are writing is pledged with misaligned code). You have to write fairly different code in space-lua and in Lua 5.4 now.

Is there any chance to fix this, please? (Or at least discuss it?)

select(index, ...) docs: If index is a number, returns all arguments after argument number index; a negative number indexes from the end (-1 is the last argument). Otherwise, index must be the string "#", and select returns the total number of extra arguments it received.

# (uses __len metamethod) docs: __len: the length (#) operation. If the object is not a string, Lua will try its metamethod. If there is a metamethod, Lua calls it with the object as argument, and the result of the call (always adjusted to one value) is the result of the operation. If there is no metamethod but the object is a table, then Lua uses the table length operation (see §3.4.7). Otherwise, Lua raises an error.

---

Finally, while writing this, the §3.4.7 explained the whole thing...