Resolve a set of critical bugs in SERCOM and unify SPI/UART/I2C baudrate calculations

[crabel99]

This PR supersedes #737, which can be closed.

There are a series of bugs relating to:

1. Setting of GCLK->PCHCTRL[clk_id].reg = GCLK_PCHCTRL_GEN_GCLK1_Val | (1 << GCLK_PCHCTRL_CHEN_Pos) to values that exceeded Table 54-6 (see also Table 14-9) values for clk_id =3 (FDPLL0 and FDPLL1 Reference clock frequency) by 3,750%. The code had originally missed in the datasheet where the CORE clock controls the SERCOM frequency, Section 36.5.3:

Two generic clocks are used by `SERCOM: GCLK_SERCOMx_CORE` and `GCLK_SERCOM_SLOW`. The core clock (`GCLK_SERCOMx_CORE`) can clock the I2C when working as a host. The slow clock (`GCLK_SERCOM_SLOW`) is required only for certain functions, e.g. SMBus timing. These two clocks must be configured and enabled in the Generic Clock Controller (`GCLK`) before using the I2C.

2. The calculation of baudrates particularly I2CM.BAUD.bit.BAUD and I2CM.BAUD.bit.HSBAUD that were not in accordance Section 36.6.4.2.1.1 and 36.6.4.2.1.2 for the SAM D5x/E5x and Section 28.6.2.4.1.1 and 28.6.4.2.1.2 for the SAM D21/DA1 chips.

3. It the clock of a SAM D5x/E5x was set during runtime from the default 48 MHz, there was a situation where the BAUD setting for UART and I2C was not set correctly and could have as much as 100% error between actual and desired bus baudrates.

4. There is an overflow condition in the calculation of BAUD and HSBAUD settings, recommend adding the following pseudo code to clamp I2C baudrates in initMasterWire(baudtate). With low enough baudrate it is possible to generate an overflow condition where the BAUD would be very low, e.g. 0x01 generating a baudrate that exceeds the maximum specified value.