Separate ordinary materialization from GPU materialization, examples on how to run naive matmul using both

[mstn]

Description

Previously, ordinary materialize implicitly launched a GPU kernel. This mixed functional buffer construction with GPU scheduling and made it difficult to distinguish a normal materialization from an explicitly parallel one.

The PR separates these responsibilities:

• Ordinary materialize now follows the functional interpretation:

  for i in 0 .. size:
      output[i] = producer(i)
  

  Codegen lowers it to a sequential host loop without a kernel launch or device synchronization.

• gpu.materialize remains the explicit GPU operation. It takes launch parameters and schedules one kernel invocation per logical thread.

• The existing naive matmul uses ordinary materialize.

• A new GPU naive matmul uses the same matrix-view and cell-dot logic through gpu.materialize, making the scheduling choice explicit.

Only nested gpu.materialize are not allowed because we don't want to launch kernels from a kernel for now.

Tests

• Ordinary materialize with naive matmul:

  • Checks the numerical matrix-multiplication result.
  • Verifies codegen emits a sequential host loop.
  • Verifies no GPU kernel launch or device synchronization is generated.

• gpu.materialize with naive matmul:

  • Checks the numerical result against the expected matrix.
  • Verifies codegen emits a GPU kernel, explicit launch, and synchronization.

• gpu.materialize with tiled matmul:

  • Tests multiple output and inner tiles.
  • Tests identity matrices supplied directly as closures on either side.
  • Checks all numerical results.
  • Verifies cooperative shared-memory loads and block synchronization are generated.

[mstn]

outdated after #152