spv: minimal OpSpecConstantOp and OpConstantFunctionPointerINTEL support.

[eddyb]

_{(each commit should be reviewed separately)}

Temporarily based on:

• Split a new mem module (for "memory" ops/passes/etc.), out of qptr. #25

---

The OpSpecConstantOp support is pretty simple/limited (i.e. interpreting LiteralSpecConstantOpInteger operands as a SPIR-V opcode followed by all the operands an instruction with that opcode would need).

While OpSpecConstantOp can be used to do simple arithmetic on specialization constants (as its name may imply), it's also SPIR-V's equivalent of a LLVM ConstantExpr, so it includes the kind of pointer operations (e.g. OpAccessChain and OpBitcast) necessary to produce non-trivial pointer values for e.g. initializing globals.

Actually doing anything with such constants isn't implemented, but being able to load a SPIR-V module containing them is a prerequisite for generating them within Rust-GPU for better diagnostics and debuggability etc.

---

OTOH, OpConstantFunctionPointerINTEL support is far more involved, due to two related issues:

• SPIR-T had no way to refer to a Func from a Const (ConstKind::PtrToFunc had to be added)
• constants come before functions, so SPIR-V -> SPIR-T has to account for the forward reference
  (done by allocating a Func with a dummy declaration, later replaced by the actual function)

SPIR-T -> SPIR-V is much easier, just because all the IDs in the module get allocated early anyway.

On top of the constants themselves, function pointer types (i.e. using CodeSectionINTEL as the storage class) are intentionally ignored by qptr, as all plans for some kind of function pointer emulation (likely as part of recursion emulation) don't really fit the qptr framework and would work more like a disjoint address space (a la Harvard architectures).

But just like with OpSpecConstantOp, the main usecase right now is limited to diagnostics/debuggability.