Split --<scheme>-to-lwe into "trivial/common" and "real" lowering parts

[AlexanderViand-Intel]

In my --<scheme>-to-openfhe to --lwe-to-openfhe merger (PR #1196), I'm using --<scheme>-to-lwe in its current form to lower only the "common" operations we already have in the lwe dialect (e.g., add, mul, etc.) to reduce the amount of scheme specific ops that the openFHE pipeline needs to deal with. The current form of this pass leaves many operations (e.g., <scheme>.rotate, bgv.mod_switch, etc) unmodified, which is fine for the OpenFHE pipeline.

However, we will eventually want to extend --<scheme>-to-lwe to declare all <scheme> ops illegal and lower such operations to lwe (necessary for lowering to polynomial). There's a good chance that this lowering will be directly to "building blocks", e.g., a rotate might lower to an explicit permutation/automorphism + keyswitch operation, rather than lwe.rotate. As a result, the output of this extended pass would no longer be suitable for the OpenFHE piepeline.

This issue exists as a reminder to turn --<scheme>-to-lwe into a pipeline with two passes: first, a --<scheme>-common-to-lwe pass with the current behavior that lowers only trivial/common ops, and a --<scheme>-specific-to-lwe pass that lowers the remaining ops, potentially "below" the library backend abstraction level.

[asraa]

Nice! I wonder if that behavior can just be controlled by a difference in what the ConversionTarget declares is legal/illegal.

[AlexanderViand-Intel]

Nice! I wonder if that behavior can just be controlled by a difference in what the ConversionTarget declares is legal/illegal.

Ohh, I like the idea! That might mean this could even just be controlled by a pass flag, so I updated the issue name to be more generic.