fix(semantic): preserve vararg bindings and result types

[lewis6991]

Vararg uses are missing from reference collection after the rewrite. This produces false unused warnings and prevents definition and reference queries from finding ...:

local function forward(...)
    print(...)
end
forward('hello')

Record each use against the nearest function's vararg declaration. A use in an inner function must not mark the outer function's varargs as used.

Type inference also confuses repeated tuple values with separate result slots. These annotations describe different arguments:

---@param ... [string, integer]
local function tuples(...)
    local packed = {...}
    return packed[2] -- [string, integer], the second tuple table
end
tuples({'a', 1}, {'b', 2})

---@param ... [string, integer]...
local function sequence(...)
    local packed = {...}
    return packed[2] -- integer, the second value
end
sequence('a', 1)

VariadicType::Base previously represented both repetition and declared tuple expansion. Add Repeat(LuaType) for repeated whole values. Keep Base for declared T... expansion, which can wait until generic types are known, and Multi for known result slots.

Carry this distinction through forwarding, table packing, generic callbacks, and select, pcall, and xpcall. Apply Lua's single-value adjustment to parentheses, operators, index keys, and non-final expressions:

---@param ... integer
local function counts(...)
    return select('#', ...),       -- unknown count
           select('#', (...)),    -- one value
           select('#', ..., 'x')  -- two values
end

Keep callback parameter compatibility separate from result value compatibility. An integer result can supply a number result, while incompatible callback parameters and redundant direct-call arguments still produce diagnostics.