Reduce overload explosion in constructors.kt

`multik-core/src/commonMain/kotlin/org/jetbrains/kotlinx/multik/api/constructors.kt` has grown to ~1600 lines with ~110 public functions. Most of them are mechanical variations of `ndarray(...)` over dimension (D1–D4), primitive type, input container (List / Array / Collection), and Number vs Complex.

### Problems

- Heavy duplication — every new variation multiplies across all axes.
- `@JvmName("ndarrayComplex")` disambiguation is not discoverable from the API.
- Known perf issue: `// TODO: boxing/unboxing!!! Find all usages` at line 449.
- Maintenance cost: adding one new input shape requires touching dozens of overloads.

### Suggested direction

- Generate type-specific overloads (template-based, similar to stdlib `_Arrays.kt`, or KSP).
- Shrink the public surface to a small set of canonical constructors (primitive array + shape) and derive the rest.
- Fix the boxing path flagged by the TODO while reworking the layout.

Start by reading multik-core/src/commonMain/kotlin/org/jetbrains/kotlinx/multik/api/constructors.kt, especially the boxing TODO at line 449, and compare its overload structure with the Kotlin stdlib _Arrays.kt or a KSP approach. The issue is complete when the constructor surface is reduced or generated, the overload duplication is addressed, and the flagged boxing path is resolved.

Written by the indexing model from the issue text.