[TIR] Support AllocateConst nodes in TensorIR scheduling flow

[masahi]

TIR-level constants, represented by AllocateConst nodes, were introduced in #8509. They are generated if link-params = 1.

At Relay level, link_params = True makes constant tensors kept bound to the function body, rather than lifting them to function parameters during FuseOps. So we end up with the following Relay prim func, for example:

fn (%p0: Tensor[(128, 768), uint8]) -> Tensor[(128, 768), int32] {
  nn.contrib_dense_pack(%p0, meta[relay.Constant][0], units=None, out_dtype="int32", weight_layout="NC32n4c")
} 

(if link-params = False, which is the default, the weight also becomes the parameter of the function).

I found that TensorIR related components below do not support such TIR-level constants currently:

• CreatePrimFunc: It assumes that all tensors will be passed as parameters. This doesn't hold if link-params = 1.
• PlanAndUpdateBufferAllocationLocation: Handling for AllocateConst nodes is incorrect. It creates a duplicated allocation for constant already allocated by AllocateConst node, which StorageRewrite complains because there are two allocations of the same-name constant.
• LeafBlockRemovalPlan (used by compute_at and compute_inline): Assumes that the body of Block begins with SeqStmt. This may not be the case since I placed AllocateConst at the beginning of a body, like below

def main(...) -> None:
    ...
    fused_nn_contrib_conv2d_NCHWc_constant_1 = T.allocate_const(..., "int32", [1, 16, 1, 1, 4])
    fused_constant_0 = T.allocate_const(..., "int8", [16, 16, 3, 3, 1, 4, 4])
    for i0, i1, i2, i3, i4 in T.grid(1, 16, 58, 58, 4):
       ...

The most important change is the introduction of CreatePrimFuncWithConstants function. It reuses tir::BindParams pass added in #8509 to create a PrimFunc with AllocateConst nodes. Since this new function takes an array of runtime::NDArray as an additional argument, I had to change all places where CreatePrimFunc is used.

cc @junrushao1994 @Hzfengsy @vinx13 @csullivan

[masahi]

Please note this change. This places AllocateConst at the beginning of the body of BlockRealize. I found that putting BlockRealize as the body of AllocateConst leads to many issues since many places in TIR code assume that the body of a primfunc starts with BlockRealize.

[Hzfengsy]

LGTM

[Hzfengsy]

Thanks @masahi