stm32: generated code for rcc(scalar)<->u8 mapping can result in bloat

[peterkrull]

Discussed this in the matrix chat, posting here to track the issue.

Some chips will have multiple KiB of bloat in the binary due to the sometimes very large match statements generated here.

For example, the stm32f405, has the following generated code:

impl core::ops::Mul<crate::pac::rcc::vals::Plln> for crate::time::Hertz {
    type Output = crate::time::Hertz;
    fn mul(self, rhs: crate::pac::rcc::vals::Plln) -> Self::Output {
        match rhs {
            crate::pac::rcc::vals::Plln::MUL50 => self * 50u32 / 1u32,
            crate::pac::rcc::vals::Plln::MUL51 => self * 51u32 / 1u32,
            // ... few hundred lines later
            crate::pac::rcc::vals::Plln::MUL431 => self * 431u32 / 1u32,
            crate::pac::rcc::vals::Plln::MUL432 => self * 432u32 / 1u32,
            #[allow(unreachable_patterns)]
            _ => unreachable!(),
        }
    }
}

which is obviously very inefficient when in this case this would suffice:

impl core::ops::Div<crate::pac::rcc::vals::Plln> for crate::time::Hertz {
    type Output = crate::time::Hertz;
    fn div(self, rhs: crate::pac::rcc::vals::Plln) -> Self::Output {
        self / rhs.to_bits()
    }
}

However it is not the case for many other chips that the rcc:u8 relationship is 1:1 like this.

For some targets, some amount of size reduction can be had by inlining init_pll, since it may be called multiple times. Though the biggest reduction can be had if init_pll is inlined and the giant match can become smoller. Dirbaio suggested to make the code generation smarter at detecting simple cases like this, and use simpler code instead.