As mentioned in today's meeting, no longer needing to specify the scheme as a flag makes building the compilation/translation pipeline much nicer, especially in the Python frontend.

The scheme flag was really only used for two decisions:

• in getModulePrelude, to decide whether to emit CryptoContextBGVRNS or CryptoContextCKKSRNS
• around encode/decode, to decide whether to use getPackedPlaintext or getCKKSPackedPlaintext and to check consistency

The latter use was entirely redundant, as the encoding info on the op (or on the plaintext type of the result/operand) already clearly indicates what should be used. Ensuring consistency is now achieved via verifiers on openfhe.make_packed_plaintext and openfhe.make_ckks_packed_plaintext.

Unfortunately, the first use wasn't quite as easy to get rid of and required introducing a (hopefully somewhat temporary) helper attribute: the --secret-to-<scheme> passes now add an attribute to the module (e.g., {bgv.scheme}) which the openfhe emitter inspects.