Include DOLRECOMP_STATE_MEMORY in the codegen cache identity

[dougchansan]

DolRecomp reads DOLRECOMP_STATE_MEMORY from the ambient environment and it changes the code it generates: state-in-memory keeps CPU state in CPUState instead of allocas, which produces a very different — and roughly 3× smaller — module. The variable was not in the cache key.

Everything else that distinguishes such a pair of builds is already keyed or identical, so two builds that differ only in this variable hash to the same identity and the cache answers one with the other:

arm	backend	DOLRECOMP_STATE_MEMORY
llvm	llvm	0
sim	llvm	1

Same backend, same recompiler binary, same DOL. backend= is already part of the identity string and is equal here, and DolRecompCodegenIdentity() contributes nothing for a name absent from the array — so before this change the two identities are byte-identical.

After it they separate, which is what the cache directory names show:

llvm  ...-3583cf731fa2e16c
sim   ...-f0315f9002dfe831

Nothing is contributed when the variable is unset, so a default environment keeps the cache entries it already has and no existing module is invalidated.

This is the same class of bug the existing comment above the array describes for DOLRECOMP_LLVM_CPU — a variable DolRecomp reads via getenv that changes generated code but did not reach the key.

[siahisaforker]

Superseded by the --state-in-memory interface handled in #33.