p9_tor: fix some random bytes in TOR image

There are 4 padding bytes needed for an 8 byte alignment at the end
of the TOR slot array for PERV common rings, which sometimes
exhibited non-zero content. These could have been mistaken as
valid offsets pointing to rings that didn't exist in the image,
if a users assumed a 16th PERV common ring, which might be added
in the future.

The original code used an array and a loop - which didn't account
for padding bytes - to zero all slots. A following memcpy() - which
accounted for padding bytes - copied bytes beyound the array boundary.

This code was a total mess anyway, and hence it is replaced by single
memset(), which uses a corrected size value.

This problem was only found in the function used for ring slots.
Nevertheless, similar code has been cleaned up for two other
use cases.

Change-Id: I1c81518ff81a6af735240090cdbc7735f60f3edb
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/37287
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: PPE CI <ppe-ci+hostboot@us.ibm.com>
Tested-by: Hostboot CI <hostboot-ci+hostboot@us.ibm.com>
Reviewed-by: Claus M. Olsen <cmolsen@us.ibm.com>
Reviewed-by: Martin Peschke <mpeschke@de.ibm.com>
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/37293
Reviewed-by: Hostboot Team <hostboot@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>

src/import/chips/p9/utils/imageProcs/p9_tor.H

@@ -56,6 +56,12 @@ typedef struct
     uint32_t TorPpeBlockSize;
 } TorPpeBlock_t;
 
+typedef struct
+{
+    uint32_t commonOffset;
+    uint32_t instanceOffset;
+} TorCpltBlock_t;
+
 typedef uint16_t TorRingOffset_t;  // Ring offset value in TOR offset slot
 
 #define TOR_SUCCESS                           0