fix(PeriphDrivers): Fix UART clock source issues

[hfakkiz]

Description

With new UART RevB clock source selection updates, some problems occurred on Zephyr RTOS side. Also, I noticed some problems about MSDK side too. In this PR,

• Fixed these build issues.
• Disabled GPIO and clock enablement for Zephyr side.
• To avoid from duplication, I moved clock source enablement from init function to clock source selection function.
• Added get function for clock source for ME15 and ME21

Checklist Before Requesting Review

• PR Title follows correct guidelines.
• Description of changes and all other relevant information.
• (Optional) Link any related GitHub issues using a keyword
• (Optional) Provide info on any relevant functional testing/validation. For API changes or significant features, this is not optional.

[sihyung-maxim]

Oh boy, another one lol. Changes looks good, double-check me @Jake-Carter

[ozersa]

Need to be rebased first.

[hfakkiz]

Rebased.

[sihyung-maxim]

Is there a reason why the MXC_UART_SetClockSource function for certain parts writes to a clock_option variable within the switch statement, then calls the MXC_UART_RevB_SetClockSource function at the end while other parts follow this setup?

[hfakkiz]

Is there a reason why the MXC_UART_SetClockSource function for certain parts writes to a clock_option variable within the switch statement, then calls the MXC_UART_RevB_SetClockSource function at the end while other parts follow this setup?

When I review MXC_UART_SetClockSource functions I noticed that, if UART instances use same clock sources for clock options then MXC_UART_SetClockSource function calls MXC_UART_RevB_SetClockSource function within the switch statement but if UART instances use different clock sources for clock options then it writes to clock_option variable and at the end it calls the MXC_UART_RevB_SetClockSource function. I followed same structure.

[Jake-Carter]

Thanks @hfakkiz, my mistake. I didn't consider MSDK_NO_GPIO_CLK_INIT