calculate and check shifts only when they are actually used

The integration of JVET_M0297_32PT_MTS_ZERO_OUT adds unnecessary code as
well as unnecessary processing in the encoder quantization process. -
The suggested change simplifies the code and avoids unnecessary
processing for the zero-out region.

The suggested changes fix the following two issues:

[1]
For blocks with width>32 or height>32, the scan created in initRom()
(file Rom.cpp) are only valid for the non-zero-out region. However, in
Rom::xInitScanArrays() (file DepQuant.cpp), the zero-out region is also
used. This has the effect that the array raster2id[] contains wrong
values. As a consequence, wrong neighboring positions cpos[] are derived.

Even though a previous fix (fix #161) ensures that the positions are
clipped to a value inside the subblock, these positions could still be
wrong. It is suggested to fix the issue by correctly considering the
zero-out regions for larger blocks (which is the actual source of the problem).

[2]
In State::updateStateEOS(..), the array m_absLevelAndCtxInit should be
set equal to zero if a skipped subblock is selected. Otherwise, it could
be possible lead to a usage of wrongs contexts for following transform
coefficients.

In Rom::xInitScanArrays()

Decoder analyser did not work. This corrects the problem, removes unused
entries and corrects the orders of strings vs enum list.

Make sure that the position of the sample in the template falls
in the same subblock as the current sample before subtracting the
offset of the begining of the subblock.

Refactor code to make lines fit within a reasonable of characters.

Large blocks, i.e. with either width or height equal to 64, have
fewer coefficients. The number of coefficients should thus be
set accordingly

This reverts commit 3574c11d.

There is a conflict with JVET_M0427_INLOOP_RESHAPER that is triggering a debug assertion that checks that the width is not 1.