[TIR] Use constructor for new PrimFunc in TransformLayout

[Lunderberg]

Using the constructor applies all initialization steps and error-checking, where using CopyOnWrite() does not. This function is used as part of the legalization of relax.op.layout_tranform, which relies on the annotations produced in the PrimFunc constructor.

[slyubomirsky]

Good to see safer interfaces and checks for consistency.

[Lunderberg]

CI failure is for tests/python/relay/test_auto_scheduler_tuning.py::test_tuning_cuda. It looks like a flaky test, which occurs whenever the randomized tuning fails to find any valid schedules. I can reproduce the failures on main, and have submitted #16837 to disable the test. After that PR lands, I'll re-run CI for this PR.

[Lunderberg]

Rebased this PR onto main as #16837 has now landed.

[Lunderberg]

In the future, I'm wondering if the CopyOnWrite functionality should be extended to perform this type of initialization. Currently, regardless of what invariants are established by an object's constructor, they can be violated when overwritten with CopyOnWrite.

We could have CopyOnWrite return a proxy object, rather than T::ContainerType*. The proxy object would provide operator->, so the same obj.CopyOnWrite()->foo = new_foo would still function as intended. However, on destruction, the proxy object would call some T::Validate method. That way, we get the usability of direct access and CoW to mutating a single field, but we can still establish invariants for classes.