In the menuconfig target, the context dependency was executed before kconfig-mconf.  That was necessary because the link at apps/platform/board needed to be set up before creating the apps/Kconfig file.  Otherwise, the platform Kconfig files would not be included.  But this introduces the chicken-and-egg problem in some configurations.

In particular:  (1) An NX graphics configuration is used that requires auto-generation of source files using cpp, (2) the configuration is set for Linux, but (3) we are running under Cygwin with (4) a Windows native toolchain.  In this case, POSIX-style symbolic links are set up but the Windows native toolchain cannot follow them.

The reason we are running 'make menuconfig' is to change from Linux to Cygwin, but the target fails.  During the context phase, NX runs CPP to generate source files but that fails because the Windows native toolchain cannot follow the links.  Checkmate.

This was fixed by changing all of the make menuconfig (and related) targets.  They no long depend on context being run.  Instead, they depend only on the dirlinks target.  The dirlinks target only sets up the directory links but does not try to run all of the context setup; the compiler is never invoked; no code is autogeneraed; and things work.

lib_dumpbuffer:  Now prints a large on-stack buffer first to avoid problems when the syslog output is prefixed with time.

Pwm_driver

drivers/serial/pty.c, serial.c, usbdev/cdcacm.c, include/nuttx/fs/ioctl.h:  Fix FIONWRITE and add FIONSPACE.  All implementations of FIONWRITE were wrong.  FIONWRITE should return the number of bytes waiting in the outgoing send queue, not the free space.  Rather, FIONSPACE should return the free space in the send queue.

configs/stm32f4discovery/canard: Change version to lastet. Need to match change to apps/libcanard/Kconfig

SAM3/4 USB and USBMSC fixes.

This fixes a race condition where the HW fills a FIFO bank while the SW is
busy, resulting in out of sequence USB packets.

The scsi thread was waiting for the wrong condition.

However, this was masked by the fact that the code creating the scsi thread
was also holding usbmsc_scsi_lock(priv) while initializing data, hence this
lock synchronized the scsi thread start with init completion.

Fix STM32 RTC Alarm interrupts.  They were being enabled BEFORE the interrupt system was being initialized.

Back out last RTC alarm changes.  I am mistaken, the interrupts are enabled by stm32[l4]_exti_alarm().