`--secret-to-bgv` options are "underconstrained" w.r.t. parameter selection

[AlexanderViand-Intel]

Currently, --secret-to-bgv only allows specifying poly-mod-degree and (optionally) coefficient-mod-bits.

If we wanted to go for a "the compiler does everything for you" approach to parameters and noise managemend, we'd probably want to switch this to be poly degree and plaintext modulus, as this would be sufficient to define the semantics of the plaintext space, and everything else could be made transparent to the developer / higher-level components.
Note that we'd need to be able to specify not just the plaintext modulus bits, but the actual modulus $p$. In fact, as some use cases require plaintext spaces like $\mathbb{F}_{p^d}$, we'd probably also need to have an (optional, default=1) option for $d$. (EDIT: Though we could start without $d$ and add support for such adanved cases later)

Alternatively, or as a second set of options that trigger the pass to forgo it's own parameter selection logic, we'd need to be able to specify the degree and plaintext as above, but also the ciphertext modulus. Again, not just the bits, but the actual modulus (or moduli, in case of RNS).

[asraa]

Once https://gist.github.com/asraa/6105c144aa10295aa4f021438d5b046d is inscribed into LWE types, I assume we'll have a place for that, and then the Action Item for this issue would be to update the conversion pass.

[j2kun]

Let's be sure to specify p as a typed attribute (e.g., 8346582371 : i32 or 834754387 : i64) and we can have any pass options parse the attribute string.