Workaround for false positive -Wmaybe-uninitialized being triggered on some compilers

Some toolchains (in this case referring to a g++ 4.9, or "arm-linux-
androideabi-g++ (GCC) 4.9 20140827 (prerelease)" according to my
--version, from the Android NDK r10e-rc4 and potentially with custom
patches; others may be affected as well) fail to prove that myVec in
WebRtcIsac_CorrelateInterVec is never used uninitialized. This is likely
due to the compiler thinking the assignment in line 468 might not
happen. Changing the loop condition in line 466 to rowCntr <
SOME_CONSTANT also helps, suggesting that the compiler can't infer that
there are only 2 values interVecDim can have at that point, and neither
of them are 0. Of course, this is not an acceptable fix, as it changes
behaviour.

This seems to be a compiler bug, or at least an issue with its
heuristics. However, we can't really change toolchains at the moment,
and ultimately this change improves support for certain older compilers.

BUG=

Review URL: https://codereview.webrtc.org/1406423004

Cr-Commit-Position: refs/heads/master@{#10337}

webrtc/modules/audio_coding/codecs/isac/main/source/encode_lpc_swb.c

@@ -440,7 +440,7 @@ WebRtcIsac_CorrelateInterVec(
   int16_t rowCntr;
   int16_t colCntr;
   int16_t interVecDim;
-  double myVec[UB16_LPC_VEC_PER_FRAME];
+  double myVec[UB16_LPC_VEC_PER_FRAME] = {0.0};
   const double* interVecDecorrMat;
 
   switch(bandwidth)