Add ConstKind::Undef (i.e. SPIR-V OpUndef).

[eddyb]

Note: this PR is a draft to avoid accidental merging onto its "base" branch (used as a form of ad-hoc PR stacking), and will remain as such, until its "base" branch can be set to main, i.e. all prerequisite PRs will have landed, up to and including this PR (whose branch is the "base" of this one):

• WIP: hermetic (on the output side) loops. #36

---

This would be a a pretty simple addition: a SPIR-T "native" equivalent of SPIR-V OpUndef / LLVM undef, mainly simplifying the creation of "filler" constants for dynamically-unused dataflow outputs etc.

---

Except that SPIR-V is moving towards "poison" (including a brand new extension, SPV_KHR_poison_freeze), following in the footsteps of LLVM - see also:

• LLVM docs for (now deprecated) undef vs poison
• "Undef and Poison: Present and Future" slides from 2020

One of the places where AFAICT they're willing to be more aggressive than LLVM, is "uninitialized memory" - OpVariable seems to now default to a poison initializer, not undef.

It's not unclear at this moment how much of undef+poison should be modeled in SPIR-T, but some could help.