pinctrl: introduce pin configuration autogenerator

[gmarull]

This PR adds support for autogenerating valid pin configurations for GD32 devices based on a set of configuration files build from datasheets/reference manuals. The script supports both, devices using the remap model, e.g. GD32F103 and devices using the alternate function model, e.g. GD32F450.

The autogenerated definitions contain the following information:

Remap/AFIO model:

• Port (e.g. A, B, C...)
• Pin number (0...15)
• Mode (input, alternate, analog)
• AFIO configuration (PCF0/1, PCFx position, PCFx width, PCFx selection)

AF model:

• Port (e.g. A, B, C...)
• Pin number (0...15)
• Mode (ANALOG, AFx, x=0..15)

The definitions can be used later in a pinctrl driver like this:

#include <dt-bindings/pinctrl/gd32vf103c(b-8)xx-pinctrl.h>

&pinctrl {
    usart1_default: usart1_default {
        pins1 {
            pinmux = <USART1_TX_PD5_RMP>, <USART1_CTS_PD3_RMP>;
        };
        pins2 {
            pinmux = <USART1_RX_PD6_RMP>, <USART1_RTS_PD4_RMP>;
            bias-pull-up;
        };
    };
};

Considerations:

• Remap suffix is added for signals that can be remapped (AFIO model). This makes it easier to spot misconfigurations (all signals need to have the same suffix on a peripheral, since remap happens to all peripheral signals)
• Linux model for STM32 is considered for representation. This model is quite flexible and allows solving problems like this which can't be solved in a node-based approach. Node-based approach also requires to generate a node per supported state, making it harder to extend to future states.
• No "defaults" are introduced as in STM32 (not possible with defines anyway). While it's true that in some cases some settings will always be applied, e.g., open-drain for I2C, many others depend on PCB layout or peripheral operating conditions. Therefore, it doesn't make sense to add "defaults".