[AMDGPU] Add DummySchedWrite to avoid multiple issue cycles (#190095)

TargetSchedule.td specifies that each explicit def of an instruction
must have an associated SchedWrite type. This is a bit unfortunate due
to the MachineScheduler handling of the ScedWrites.

Each of these different SchedWrite contribute to the number of MicroOps
for the MCSchedClassDesc for the instruction --
https://github.com/llvm/llvm-project/blob/096f9d0aa8edb8bad77e8061a6aa9cbf61bcb5ac/llvm/utils/TableGen/SubtargetEmitter.cpp#L1136

Then in the MachineScheduler.cpp's bumpNode, we grab the numMicroOps
from the MCSchedClassDesc
https://github.com/llvm/llvm-project/blob/3d7eedce5658c41a1b22775938359bfafac47fc9/llvm/lib/CodeGen/MachineScheduler.cpp#L2948

We then use this numMicroOps as how many micro ops we'll need to issue
for this instruction. For our target, the issueWidth per cycle is 1. So,
for these instructions the MachineScheduler thinks they will take
multiple cycles to issue, and we add stalls to the hazardRecognizer
https://github.com/llvm/llvm-project/blob/3d7eedce5658c41a1b22775938359bfafac47fc9/llvm/lib/CodeGen/MachineScheduler.cpp#L3100

Adding these unnecessary stalls throws off analyses in the
HazardRecognizer, which can lead to suboptimal scheduling decisions.

Due to the design, we are essentially pigeonholed into misrepresenting
these instructions. This PR adds new SchedWrite types ( WriteVALUDummy
and WriteSALUDummy ) to honor the rule of "each explicit def must have a
SchedWrite" without adding unnecessary MicroOps to get around the issue.
There are several other instructions that have exposure to this issue,
and addressing them all at once leads to lit test churn of about 170
tests. The intention of this PR is to agree upon the approach, then we
can incrementally roll it out to other instructions.