Originally, when this code was part of 6l/8l, every new
Prog was constructed starting with zprg, which set back=2,
and then this code walked over the list setting back=1 for
backward branches, back=0 otherwise. The initial back=2
setting was used to identify forward branches (the branched-to
instruction had back == 2 since it hadn't yet been set to 0 or 1).

When the code was extracted into liblink and linked directly
with 6a/6g/8a/8g, those programs created the Prog struct
and did not set back=2, breaking this backward branch detection.

No one noticed, because the next loop recomputes the information.
The only requirement for the next loop is that p->back == 0 or 1 for
each of the Progs in the list.

The initialization of the zprg with back=2 would cause problems
in this second loop, for the few liblink-internally-generated instructions
that are created by copying zprg, except that the first loop was
making sure that back == 0 or 1.

The first loop's manipulation of p->back can thus be deleted,
provided we also delete the zprg.back = 2 initializations.

This is awful and my fault. I apologize.

While we're here, remove the .scale = 1 from the zprg init too.
Anything that sets up a scaled index should set the scale itself.
(And mostly those come from outside liblink anyway.)

Tested by checking that all generated code is bit-for-bit
identical to before this CL.

Change-Id: I7f6e0b33ce9ccd5b7dc25e0f00429fedd0957c8c
Reviewed-on: https://go-review.googlesource.com/3574Reviewed-by: Austin Clements <austin@google.com>