Decided to go ahead and move the TX Buffer there as well
Did a quick check in earlier test program to echo the contents back.

The other test program was already setup to receive data on the HID and does hex dump of buffer which looks correct.  So far so good.

Testing against issues of hang from thread:
https://forum.pjrc.com/threads/59881-RawHID-recv()-hangs-after-updating-to-Teensyduino-1-4-9-or-higher-for-Teensy-4-0/page2

F_CPU -> F_CPU_ACTUAL

- trap unused memory regions
- trap nullptr
- trap stack overflow

This answers a long standing question :-)

https://github.com/PaulStoffregen/cores/issues/424#issue-555760117

see RM V2 Page 3221

https://forum.pjrc.com/threads/59815-teensy-4-0-XBAR-questions?p=231803&viewfull=1#post231803

https://forum.pjrc.com/threads/59815-teensy-4-0-XBAR-questions

It was defaulting to the same NUM_DIGITAL_PINS and NUM_ANALOG_INPUTS as the T4.0 so updated for the new pins

There are two pins on the SDCard IO pins that are valid alternate pins for Serial5
Serial5.setRX or setTX.

These pin numbers changed from T4 to T4.1 so update table depending on which board.

Serial8 is now defined for T4.1.

Previously it was defined for T4B1, but went away on T4B2 and released.  It is now defined on the T4.1

This can be adjusted easyly by editing maxSpeed and maxSpeedBeforeDelay

The fix of IOMUXC_GPR_GPR16 disabled the power-off on panic-alarm, this should fix it.

Needs accompanying changes in Arduino's boards.txt, enabling corresponding menu entries

Sorry pasted in wrong code.

Migrated the T3 code over to handle the message to set the logical keyboard LEDS

As per forum thread: https://forum.pjrc.com/threads/59372-Teensy-4-0-no-support-for-keyboard_leds

Extracted from other PR.

This change only adds the code to look at the RX FIFO when you call available, and read/peak if our software queue is empty, it then checks to see if hardware FIFO has data to extract.

Longer term we might consider changing timer over to using system clock, with default(max) divisior of 4 to go to PID instead of fixed 24mhz...

But in the mean time, try to allow IntervalTimer Settings that work at least as well as default settings for T3.2 whoes BUS speed is 48mhz, so the magic number of 36 was used which allowed a minimum value passed into begin/update of 36
48*.75-.5

With T4 code we just blindly left the magic number of 36...  So this one simply sort of halves it.  24*.75-.5 ... I rounded down to 17

fixes #293, fixes #414