Add arith.select Pattern to --secret-to-bgv

[AlexanderViand-Intel]

This adds the following rewrite pattern:

%res = arith.select %c, %t, %f
// turns into
%ct = bgv.mul %c, %t
%nc = bgv.negate %c  // EDIT: actually a bug, this should be logical negation, i.e., bgv.sub %one, %c 
%ncf = bgv.mul %nc, %f
%sum = bgv.add %nc, %ncf
%res = bgv.relinearize %sum 

However, as-is, this pattern actually produces invalid IR: %c has (element/self) type i1 while %t and %f can have any IntegerLike type, e.g., i32. In the current TypeConverter, this means that the condition is mapped to a ciphertext with encoding #lwe.polynomial_evaluation_encoding<cleartext_start = 1, cleartext_bitwidth = 1> while the other values are mapped to ciphertexts with encoding #lwe.polynomial_evaluation_encoding<cleartext_start = 32, cleartext_bitwidth = 32>. Since bgv.mul requires the types of its operands to match, this is invalid IR.

In the current draft, I've simply hardcoded the typeconverter to map everything to 32 bits (that's why this is a Draft PR only for now), but we'll need to think about how to handle such cases. I think this is a special case of "what is the plaintext-FHE semantics mapping" (Step 1 in #785).

[AlexanderViand-Intel]

@asraa In today's meeting, I said this only needed a small bugfix, because I only remembered that I still need to swap bgv.negate %c to bgv.sub_plain %one, %c, However, I had forgotten about the real blocker here, which is the typing issue.

I.e., this does indeed hang on the attribute/type rework (though probably not even the LWE one, but a future one for cleartext<>plaintext semantics cleanup)