Honor __len in Lua 5.2 table-library operations

[XinyuGuan]

Fixes #361.

Table-library operations currently read ArrayLength instead of invoking __len. Use the existing VM length-metamethod dispatch and await asynchronous handlers. unpack and concat evaluate it only when their upper bound is omitted or nil; insert, remove and sort use it for their operation range.

Lua 5.2 requires the element accesses themselves to remain raw. Shifting and sorting therefore use raw table keys within the logical range, rather than assuming the backing array's size or sequence length is the intended range. This also handles an empty/custom length, values beyond the logical end, and a length larger than existing storage. Invalid length results produce a Lua error.

Adds 29 regression cases: 27 fail on the original implementation and all pass with this change. Coverage includes all five functions, explicit/nil bounds, async handlers, protected errors and state reuse, raw accesses, and a hook that mutates the table. The minimal unpack reproducer matches PUC-Rio Lua 5.2.3 byte-for-byte in two repetitions.

Validation on Linux x64, SDK 10.0.401 / runtime 8.0.32:

• DOTNET_GCHeapHardLimit=0x40000000 dotnet test tests/Lua.Tests/Lua.Tests.csproj -c Release --filter "TestCategory!=ExpectedFailure": 585 passed (unchanged baseline: 556 passed).
• dotnet build src/Lua/Lua.csproj -c Release: all four target frameworks build.
• dotnet csharpier check . and git diff --check: pass.

The heap limit is needed on this server for the existing large-allocation tests; without it the unmodified suite was killed by the OS. The project-defined ExpectedFailure filter is unchanged. No performance claim is made; direct host LuaTable APIs are unchanged.

[akeit0]

Thanks!