Fix out-of-bounds write in partial decomp. feature

Reported by Clang UBSan (refer to
https://bugzilla.mozilla.org/show_bug.cgi?id=1301252 for test image.)
This appears to be a legitimate bug introduced by
3ab68cf563.  Any component array, such
as first_MCU_col and last_MCU_col, should always be able to accommodate
MAX_COMPONENTS values.  The aforementioned test image had 8 components,
which was not enough to make the out-of-bounds write bust out of the
jpeg_decomp_master struct (and fortunately the memory after last_MCU_col
is an integer used as a boolean, so stomping on it will do nothing other
than change the decoder state.)  I crafted another special image that
has 10 components (the maximum allowable), but that was apparently not
enough to bust out of the allocated memory, either.  Thus, it is
posited that the security threat posed by this bug is either extremely
minimal or non-existent.

ChangeLog.md

@@ -75,6 +75,13 @@ specially-crafted malformed JPEG images.  None of these issues posed a security
 threat, but removing the warnings makes it easier to detect actual security
 issues, should they arise in the future.
 
+9. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial
+image decompression) and detected by the Clang undefined behavior sanitizer,
+that could be triggered by a specially-crafted malformed JPEG image with more
+than four components.  Because the out-of-bounds reference was still within the
+same structure, it was not known to pose a security threat, but removing the
+warning makes it easier to detect actual security issues, should they arise in
+the future.
 
 1.5.0
 =====

jpegint.h

@@ -155,8 +155,8 @@ struct jpeg_decomp_master {
   /* Partial decompression variables */
   JDIMENSION first_iMCU_col;
   JDIMENSION last_iMCU_col;
-  JDIMENSION first_MCU_col[MAX_COMPS_IN_SCAN];
-  JDIMENSION last_MCU_col[MAX_COMPS_IN_SCAN];
+  JDIMENSION first_MCU_col[MAX_COMPONENTS];
+  JDIMENSION last_MCU_col[MAX_COMPONENTS];
   boolean jinit_upsampler_no_alloc;
 };