fixes #25931; type N {.importc: "const void *".} = pointer creates order-dependent compilation failure (#25936)

fixes #25931

This fix addresses bug #25931 — a signature hash collision with
importc-aliased pointer/cstring types.
The problem: In compiler/sighashes.nim, the hashType procedure
canonicalizes types for signature hashing. Integral types
(tyInt..tyUInt64, etc.) were excluded from canonicalization so that
types like pid_t (an importc alias) keep their backend spelling. But
pointer and cstring types with importc annotations were not excluded —
meaning a type like:
type N {.importc: "const void *".} = pointer
...would be collapsed to just pointer in the signature hash, causing
collisions when N and pointer are both used in procedure types within
the same compilation unit.
The fix (compiler/sighashes.nim:193): Adds tyPointer and tyCstring to
the list of types that skip canonicalization, right alongside the
integral types. The comment is updated to clarify this applies to
"builtin scalar-ish / pointer-like types".
The test (tests/ccgbugs/tsighash_typename_regression.nim:33-42): Adds a
regression test exercising the exact scenario — an importc pointer alias
used in both an object field type and a proc parameter type.

(cherry picked from commit 056eeeae30)

tests/ccgbugs/tsighash_typename_regression.nim

@@ -30,3 +30,13 @@ block:
 
   var x = M(x: 1)
   doAssert(x.x == 1)
+
+block: # bug #25931
+  type
+    N {.importc: "const void *".} = pointer
+    S = object
+        f: proc (_: N) {.cdecl.}
+    #var _: proc (_: pointer) {.cdecl.}
+  proc d(_: proc (_: pointer) {.cdecl.}) = discard
+  discard S()
+  d(proc (_: pointer) {.cdecl.} = discard)