motion: always include the mvcost returned by motionEstimate [CHANGES OUTPUTS]

This was a rather subtle bug that has been in the code base for some time. The
caller of motionEstimate() will often want to remove the mvcost from the
returned cost value, and in this circumstance it would go negative, and since
the returned value is unsigned it became very large, causing the encoder to
actually discard a zero-residual match.

If the stars were perfectly aligned and all of the reference ME costs became
exactly -1, *all* possible ME candidates were discarded which could lead to
crashes.

--HG--
branch : stable
cmake: use HAVE_ALIGNED_STACK=0 for x86_32 builds, even for GCC

In order to enable HAVE_ALIGNED_STACK for 32bit builds, we would need to align
our stack internally at all thread entry points and all API entry points that
might use primitives.  32bit performance is not a high priority for us at the
moment.

This fixes a number of reported crashes on 32bit builds

--HG--
branch : stable
vbv: clear row diagonal and cu SATD costs after vbv row reset was triggered

refs #45

--HG--
branch : stable
frameencoder: use m_isReferenced when configuring SAO in compressFrame()

In some pessimal situations, the slice's reference state could even be changed
by the time compressFrame() starts.  This prevents any race hazard.

--HG--
branch : stable
fix compile warning in pixel.cpp for 422 primitive setup
Merge with stable
cmake: nit
encoder: singleton m_vps nits
TComSlice: initialize m_vps pointer
align DCT8's stack to 64-bytes to avoid crash and improve cache performance