compile: fix panic and silent corruption when assigning to a field of a non-table value

[snowyukitty]

Fixes #524 .

Problem

Assigning to a field or index of a non-table value can crash the VM with a Go
nil pointer dereference, instead of raising the usual attempt to index error:

debug.setmetatable("string", {})
("Lua").key = 1
-- panic: runtime error: invalid memory address or nil pointer dereference
--   ... gopher-lua/state.go: (*LState).metatable ...

Depending on the surrounding register layout the same class of statement can also
silently corrupt a nearby value instead of erroring:

local t = {}
(5).field = 1   -- no error; writes t.field = 1

Reading the same expression is fine (return ("Lua").key raises the proper
error), so only the write path is affected.

Cause

The object of an assignment target (t in t.k = v) is compiled by
compileAssignStmtLeft with compileExprWithKMVPropagation. For a constant
object it folds the OP_LOADK into an RK (constant) operand. But that object
is operand A of OP_SETTABLE/OP_SETTABLEKS, which the VM always reads as a
register: R(A)[RK(B)] := RK(C). Operand A is only 8 bits, so the folded
constant index aliases an unrelated register — usually a silent wrong write, or a
nil dereference in metatable() when that slot is unset.

The read path (AttrGetExpr in compileExpr) already uses MV propagation, which
is why reads work.

Fix

Compile the assignment-target object with compileExprWithMVPropagation, so it is
always materialised into a register — exactly like the read path. MV never folds
OP_LOADK; keys and values keep using RK, which operands B and C accept. It is a
one-token change, after which the existing attempt to index a non-table object(<type>) error is raised, with the correct type.

Tests

Added an issue #524 block to _glua-tests/issues.lua covering the silent
corruption, the reported panic, the corrected value type in the message, and that
a valid (t).x = 1 still works. go test ./... stays green, and the regression
fails on the current base.