Introduce new Cargo features generated with cube-parse

[dbrgn]

This PR introduces four new io-* features that can be used to
differentiate between different GPIO peripheral versions. This is
required to properly implement pin mappings for I/O pins (including
Serial, I²C, SPI, etc). See #74 (comment) for more context.

Additionally, because the GPIO peripheral version don't map cleanly to
the previously used families (stm32l0x1, stm32l0x2, stm32l0x3), I added
aliases for every MCU in the STM32L0 family. Those mcu-* features
are purely used as aliases
and thus do not need to be included in the testing matrix. The features
are provided as a shortcut to the user, so that the different HAL
parameters (like GPIO peripheral version, MCU subfamily, chip package,
etc) do not need to be determined manually. MCU features should
never be used as cfg gates in the source code.

Since the HAL already uses chip packages as features (in the ADC
module), I also added a dependency from the MCU feature to the
corresponding chip package feature. I am not sure whether
using physical chip package as a selector is a good idea, but since
that's already the status quo I simply kept them.

All features are generated using https://github.com/dbrgn/cube-parse:

cargo run -- features STM32L0 -d /path/to/stm32cubemx/db/mcu/defines

This PR is a requirement to resolve #68 and #76.

CC @adamgreig @HarkonenBade @jonas-schievink @david-sawatzke @arkorobotics @rnestler

[dbrgn]

Hmm, there are multiple feature gates in the code where a semi-specific MCU is required. For example, in src/pwm.rs:

#[cfg(any(feature = "stm32l072", feature = "stm32l082"))]
use crate::gpio::{
    gpioa::{PA6, PA7},
    gpiob::{PB0, PB1, PB4, PB5},
};

That's the kind of feature gate that is unmaintainable, because it can result in a dozen different variants for the different MCUs (overspecific). It also makes it hard to verify any changes if the code is not either generated, or identical across an entire (sub)family.

Ideally, we'd use the STM32CubeMX database to generate features for the feature classes that we want to cover, similar to the io-* features. In the meantime, should I add back the stm32l052, stm32l053, stm32l062, stm32l072, and stm32l082 features so that the existing code continues to work?