Track scaling factor in encoding attr for BGV (GHS variant) and handle cross-level op

[ZenithalHourlyRate]

Related to #785.

In short, the GHS variant encodes [mQl]_t for level l instead of [m]_t. This allows more prime candidates, but requires tracking the scaling factor.

OpenFHE assumes same scaling factor for the same level, and adjust the ciphertext when mismatch so we always get a correct lowering for now.

For the compiler, when we get our own lowering (e.g. bgv-to-poly), we need to track them to ensure they are the same or handle them correctly when mismatch, if we are using parameter selection process for GHS variant (related to #1168).

This also has influence on level mgmt strategy when level mismatch (#1126), where we currently use multiple mgmt.modreduce to ensure same scaling factor, where a more efficient impl would introduce mgmt.levelreduce and adjust scaling factor.

Note that this is different from the current scaling factor definition in e.g. LWE_FullCRTPackingEncoding which is described as A scaling_factor is optionally applied on the scalar when converting from a rounded floating point to an integer..

References:

OpenFHE implements both the original BGV scheme (with unscaled messages) [17]
and the Gentry-Halevi-Smart (GHS) variant (with scaled messages) [35]. The main advantage
of the GHS variant is that the RNS moduli qi do not need to satisfy the congruence relation
qi ≡ 1 mod t to perform modulus switching.

https://eprint.iacr.org/2022/915

Brakerski et al. proposed to choose
the moduli Qi = 1 mod t. This approach, although very convenient in theory, becomes challenging
in practice when using a large t since it reduces significantly the range of possible moduli for the Qi. As a consequence, Gentry, Halevi, and Smart proposed to keep track of the scaling factor for each ciphertext instead [22]. In particular, they suggested to encrypt [QLm]t
instead of [m]t in Equation (1), which provides natural downscaling to [Qim]t as modulus switching operations are applied. However in this case, one has to pay attention when adding two ciphertexts with different scaling factors.

Handling crosslevel operations and scaling factors. The GHS variant implemented in HELib uses ciphertext-specific scaling factors. In our BGV variant, we chose a simpler approach where the same scaling factor is used for all ciphertexts at a specific level, which reduces the number of scalar multiplications.

https://eprint.iacr.org/2021/204