Prefer explicitly declared overloads over generic substitutions

[marcauberer]

What changed

• Overload resolution now prefers an explicitly declared (non-generic) overload over a generic substitution when both match a call equally well, mirroring C++ where a non-template wins over a template specialization. Implemented as a secondary tie-break in FunctionManager::breakOverloadTie, applied after the existing qualifier-specificity narrowing.
• A losing generic substitution that was only inserted for this very match is removed from its declaration's manifestation list again, so the IR generator never tries to emit a manifestation that was never type-checked (and no dead code is left behind).
• Repurposed the error-ambiguous-generic-functions test (which encoded the old "this is ambiguous" behavior) into success-generic-overload-prefers-explicit, which now asserts at runtime that the explicit foo(byte*&) overload is selected over the generic foo<byte>(byte*&).

Why

Previously, declaring both a non-generic overload and a generic one that substitutes to the same signature made the call ambiguous. This is a common and legitimate pattern (e.g. a dedicated copy constructor alongside a generic value constructor), so the non-template should win rather than error.

How it was validated

• cmake --build cmake-build-debug --target spice spicetest — builds clean
• cmake-build-debug/test/spicetest --gtest_filter='TypeCheckerTests.*:StdTests.*:-StdTests.bindings_llvm' — 296 passed, 1 skipped (net_socketsBasic)
• StdTests.bindings_llvm is excluded as it fails only due to a local environment issue (mold cannot find the LLVM AArch64 libs); it compiles cleanly. BootstrapCompilerTests are a known local environment failure.

Follow-up / known limitations

A follow-up PR adds a generic value constructor to std/type/any that relies on this overload-resolution behavior.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.