test: two packages parse the ir sources with duplicated machinery

[OmarAlJarrah]

Two test packages now read the ir sources with go/parser to derive facts a hand-written
list would otherwise have to restate, and they do it with two copies of the same machinery.

• ir/typedef_completeness_test.go has declaredConstsOfType/declaredTypeKinds, which
  hold the package's hand-written kind lists to the constants the sources declare.
• pass/validate_carriers_test.go has irTypeKinds/typeKindsIn/stringLit/irSourcePaths
  and irTypeDefImpls, which seed a walk over the sealed TypeDef sum from the same
  constants.

The reason for the copy is real — a helper in one package's test binary is not linked into
another's — but the copies are not equivalent, and neither knows about the other. pass's
reading treats a const spec that names neither type nor value as continuing the group's last
explicit type, and requires each name to carry its own value; ir's makes its own choices for
the same grammar. A change to how the ir sources declare their constants has to be found
twice, and a divergence between the two readings shows up as one package silently seeing
fewer declarations than the other.

Why it matters more than ordinary duplication

Both copies exist to stop a hand-maintained list narrowing in silence, so a copy that itself
narrows in silence defeats the thing it was written for. pass guards against that by
cross-checking its constant count against the typeDef() marker methods; ir guards its own
way. Nothing holds the two readings to each other.

Proposed direction

internal/ is already the repo's home for test and tooling infrastructure outside the
pipeline (harness, archtest, testspec), and internal/testspec is where a shared
reader belongs: one parse of the ir sources, exposing the declared TypeKind constants and
the concrete types sealed into the sum, used by both packages.

That leaves one grammar-reading to review and to test, and it removes the class of bug where
two readers of one source disagree about what it says.