[BUG] low level console i/o (up_putc) can interfere interrupt-based uart i/o

### Description / Steps to reproduce the issue

for some configurations, it's possible for a system to use both of low-level up_putc and the uart (drivers/serial/serial.c) on the console.
for an example, printf(stdout) goes to the uart and syslog() goes to up_putc.

the uart uses a semaphore (dev->xmitsem) interlocked with the kernel critical section to deal with interrupts.

although how up_putc is implemented is device-specific, it usually disables interrupts, performs polling-based i/o, and then restores the interrupts.

unfortunately, with SMP, the latter sometimes can "consume" the hardware events which would otherwise have triggered tx interrupts, which the former might be waiting for. if it happens, the former can block forever.

i was mainly looking at the esp32 implementation. but other implementations look similar.

an obvious fix would be to wrap up_putc with the critical section. but i'm not feeling too happy with the approach.

any suggestions?

### On which OS does this issue occur?

[OS: Mac]

### What is the version of your OS?

macOS 14.7

### NuttX Version

master

### Issue Architecture

[Arch: all]

### Issue Area

[Area: Drivers]

### Verification

- [X] I have verified before submitting the report.