AMDGPU: Use module flags to control xnack and sramecc

[arsenm]

This ensures these ABI details are encoded in the IR module rather than depending on external state from command-line flags. Previously, these were encoded as function-level subtarget features. The code object output was a single target ID directive implied by the global subtarget. The backend would previously check if a function's subtarget feature mismatched the global subtarget. This is avoided by making xnack and sramecc module-level properties from the start. This also provides proper linker compatibility enforcement, moving the error point earlier.

The old encoding was also an abuse of the subtarget feature system. Subtarget features are a bitvector, and later features in the string can override earlier ones. The old handling added a special case where explicit settings were preserved: ordinarily +feature,-feature should result in the feature being disabled, but +xnack,-xnack would preserve the explicit "-xnack" state, which differs from the absence of any xnack setting.

The new flags are encoded as 0/1, with the "any" case represented as the absence of the flag. I considered an explicit tri-state unknown value, but decided against it.

This also removes warnings when using these module flags on targets that do not support the corresponding feature. Previously, messages were written directly to stderr instead of using proper diagnostics. Avoiding the warning reduces burden on frontends to check which targets require the flags.

For migration purposes, the subtarget features still exist. Currently, they are still respected in the various binary tools, pending disassembler changes to determine target ID modifiers from e_flags. CodeGen requires using the module flags. An error will be raised when attempting to use the old global subtarget features. These should be removed after a migration period for frontends to update. Functionality wise, bitcode autoupgrade should work. Old bitcode will not have the flags, resulting in a different target ID in the output binary than expected, but it should run correctly.

New cl::opts exist only because it was inconvenient to update all tests using multiple xnack modes. Users should never use these.