BugFix:uart_ops_s portion of cdcacm will not be initalized with correct functions if CONFIG_SERIAL_DMA is lit.

C&P error from F7

BugFix:uart_ops_s portion of cdcacm will not be initalized with correct functions if CONFIG_SERIAL_DMA is lit.

    This fixes the issses in a C99 compatible way

Xtensa ESP32: Fixes a few issue with restoring registers on interrupt return, but there is still a problem

Back out most of 46dbbe83.  The order is correct -- or, rather, the order is the same as the order that response data is provided.  Change the order will break all other drivers.

MMC/SD:  Format changed from %d to %lu.  Must cast argument to unsigned long to avoid crash on 64-bit machine.

MMC/SD SDIO (again): This is really an endian-ness issue.  Behavior should be different on big- vs little-endian machines.

Add missing ENTRY() and RET() macros in C callable assembly language.  At one time I though the that the ESP32 support the CALL0 ABI.  I was mistaken so there may be a few more like this.

ESP32 core v2: Two changes (1) flushes the UART TX buffer in the esp32 serial shutdown routine. The ROM bootloader does not flush the FIFO before handing over to user code, so some of this output is not currently seen when the UART is reconfigured in early stages of startup.  And changes the openocd config file's default flash voltage from 1.8V to 3.3V. This is not necessary right now, but may save some hard-to-debug moments down the track (3.3V-only flash running at 1.8V often half-works and does weird things...)

This was an interesting exercise to see just how small you could get NuttX, but otherwise it was not useful:  (1) the NSH code violated the OS interface layer by callup up_getc and up_putc directly, and (2) while waiting for character input, NSH would call up_getc() which would hog all of the CPU.  NOt a reasonably solution other than as a proof of concept.

SAMV7: MCAN: Prevent Interrupt-Flooding of ACKE when not connected to CAN-BUS. An Acknowledge-Error will occur every time no other CAN Node acknowledges the message sent. This will also occur if the device is not connected to the can-bus. The CAN-Standard declares, that the Chip has to retry a given message as long as it is not sent successfully (or it is not cancelled by the application). Every time the chip tries to resend the message an Acknowledge-Error-Interrupt is generated. At high baud rates this can lead in extremely high CPU load just for handling the interrupts (and possibly the error handling in the application). To prevent this Interrupt-Flooding we disable the ACKE once it is seen as long we didn't transfer at least one message successfully.