cmd/compile/internal/ssa: fix debug location gen issue with zero width ops

Revamp the way that buildLocationLists() handles zero-width
operations, to fix a couple of problems that result in bad debug
locations.

The problematic scenario in this specific bug is where you have a
parameter arriving in a register X, then a spill of register X to
memory as the first non-zero-width instruction in the function.
Example:

    v68 = ArgIntReg <unsafe.Pointer> {ctx+0} [1] : BX (ctx[unsafe.Pointer])
    v67 = ArgIntReg <unsafe.Pointer> {ctx+8} [2] : CX (ctx+8[unsafe.Pointer])
    ...
    v281 = StoreReg <unsafe.Pointer> v67 : ctx+8[unsafe.Pointer]

The existing buildLocationLists implementation effectively buffers or
bundles changes from zero-width instructions until it it sees a
non-zero-width instruction, but doing that in this case winds up
making it look as though the parameter is live into the function in
memory, not in a register.

The fix for this to separate out zero-width ops into two distinct
categories: those that whose lifetimes begin at block start (ex:
OpArg, Phi) and those whose effects are taking place at the nearest
non-zero-width instruction (ex: OpSelect0). In this patch we now
handle the first category of ops in an initial pre-pass for each
block, and leave the second category for the main pass through the
block. See the notes on the issue below for a more detailed
explanation of the failure mode.

Fixes #46845.

Change-Id: I27488d4c041019d5a0b897b7cf53000f63aab1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/362244


Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>