MLIR types are decided by parsing their printed form in 60 places, 51 of them in the typed AST backend

Split out of the Phase 2 survey in hiraditya/Vx.1#387, because the shape of it is worse than the
plan's finding 6 describes and the sequencing advice that follows from it is
different.

What is there

60 places decide something about an MLIR type by looking at its printed form.

What they test for, most common first: memref< (27), memref<memref< (6),
!llvm.ptr (6), vector< (4), tensor< (2), struct< (1).

Six named parsers exist to do this: slice_vec_len, is_slice_operand,
memref_elem, memref_lead_dims_and_elem, parse_llvm_struct_name,
vector_align_attr.

Why the AST path's version is the worse half

The flat emitter builds MLIR as text, so reading text back is at least consistent
with how it works. The AST path builds MLIR through melior's typed builder --
it has a real Type value -- and still round-trips through the printed form:

if ty_str.starts_with("memref<memref<") {
    let inner_ty_str = &ty_str[7..ty_str.len() - 1];
    let inner_ty = Type::parse(gen.context, inner_ty_str)...

A typed value is printed, matched by prefix, sliced at a hardcoded byte offset (7,
being "memref<".len()), and parsed back into a type. There are 127 Type::parse
calls in that path and eight of those hardcoded slices, in five files.

memref<memref< is a good illustration of the cost. It is a two-level memref, and
the way to ask is to inspect the element type. Asking by prefix means every place
that cares repeats the prefix, and is_scalar_memref at lower/expr.rs:155 has to
be written as "starts with memref<, does not contain x, and does not start with
memref<memref<" -- three string facts standing in for one structural question.

What to do, and when

A small MlirTy value type (scalar, memref, vector, llvm-ptr, llvm-struct) with a
Display, matched on instead of probed.

The sequencing is the part worth deciding deliberately. I had suggested scoping this
to the flat path's 9 sites on the grounds that Phase 4 retires the AST codegen, but
that is not the plan: the AST path stays until the flat path has survived a couple of
language evolutions, which makes its 51 sites live code that every new feature is
threaded through rather than code with a deletion date.

That argues for doing both halves, and for MlirTy living in src/mlir_ty.rs (added
in the Phase 2 commit, currently holding only the scalar spelling) so both backends
share one answer rather than two.

It does not argue for doing it before Phase 4. The AST path's sites are where the
work is, and Phase 4 rewrites how that path is reached. Worth revisiting once the
decline histogram (flat decline: lines, added in hiraditya/Vx.1#387) shows what the flat path
still cannot carry -- that number is what decides how long "a couple of language
evolutions" actually is.

Not to be confused with

Expr::substitute mangling instantiated expression names at syntax/expr.rs:869
is a separate problem that finding 6 files under the same heading. The type-identity
round-trip it describes -- parse_enum_instance splitting "Option<i32>" back
apart -- is fixed for the flattener; that fix is in the Phase 2 commit on hiraditya/Vx.1#387.

Start with src/mlir_ty.rs and the 60 printed-form checks in codegen/lower/expr.rs, codegen/generator.rs, codegen/lower/stmt.rs, codegen/lower/mod.rs, and codegen/flat.rs. First review the “flat decline:” lines and Phase 4 sequencing before deciding scope. Done means both backends use a shared MlirTy value instead of parsing or slicing printed MLIR types.