fix: handle intersection type as table subtype

[EfveZombie]

Problem

Intersection types like [T...] & { n: integer } (e.g. the return type of table.pack) were not recognized as subtypes of table, causing false positive type mismatch diagnostics when assigning or passing them to table-typed targets.

This issue was discovered while investigating commit 6f07707.

Root Cause

Two places in the type checker did not account for Intersection:

1. simple_type.rs — The Table | TableConst branch's matches! macro did not include Intersection, so table = intersection_value would fail.
2. sub_type.rs / get_base_type_id — This function maps concrete types to their base type ID (e.g. Array → table), but had no case for Intersection. When all components of an intersection are table-like, the intersection itself should also map to table. Also added the missing Object mapping.

Fix

• Added LuaType::Intersection(_) to the Table compact-type match in simple_type.rs.
• Added Intersection handling in get_base_type_id: recursively checks whether all components resolve to table, and if so returns table.
• Added Object to the existing table base-type mapping (was also missing).
• Added test test_intersection_is_table_subtype covering check_type, ParamTypeMismatch, and AssignTypeMismatch scenarios.

[gemini-code-assist]

Code Review

This pull request introduces support for intersection types in subtyping logic, specifically allowing them to be treated as tables, and adds LuaType::Object to the base type identification. Review feedback indicates that the current implementation for intersections is too restrictive, as it requires all components of an intersection to be tables rather than just one. Additionally, the changes in simple_type.rs are noted as being too broad, potentially treating non-table intersections as table subtypes.