An experiement to see how much work again it would take to add the T4 methods to allow user sketches to increase the size of Serial ports RX and TX buffers, without having to edit the Source code which does it then for all sketches.

T3.x SerialN Add extra memory capabilities for Serial1-6

Also

Fixed serialEventX yield handling when you call begin multiple times

There is an issue that if you are not using the serialEvent type code and you call SerialX.begin multiple times, it will add that item to the process list multiple times, which can overrun the memory and cause crash or the like.

Fix was to check the list first and see if we are already in the list.

Wondered  if this had already been done earlier.

Was not so am trying it now.

One side effect was had to change interrupt.c as there were
#defines for things like DR, GDIR which then caused compile issues with the structure.  So renamed the defines.

Built about 3 programs with it so far.  Which appear to still be working.

Missed a few, pllus one register fields name had wrong register name

https://forum.pjrc.com/threads/63842

https://forum.pjrc.com/threads/63230-map()-returns-different-values-on-arduino-vs-teensy

Allow specific interrupt level for DMA ISR.

Added in define in standard Arduino setup.

I also added for 7E1 and 7O1 as well.

Migrating the half duplex support I did in the Stagnant and out of date PR to enhance Uarts: https://github.com/PaulStoffregen/cores/pull/419

To try to support Half duplex mode in a similar way like we do for RS485 like support.

With T3.x made use of bitband address for the TX Direction setting, so
Except for the begin which calls format, no code changed, we simply stored the bitband address of the TXDIR flag into the TXDIR variable that was already used for the set direction flag.

For T4.x - it is a little more work as there is no bitband support on M7 processors.  For GPIO there is a Set and Clear register which we use, but for the appropriate UART register there is no such setup of registers.  So I have to special case we are in that mode and do it... Also since not atomic I cli/sei...

Serial Half Duplex - Fix T4Serial1 and T-LC Serial1-3

Updates: T4
T4 Serial 1 did not have proper settings for IOMUXC_LPUART6_TX_SELECT_INPUT

Tested T4.1 Serial1-8

Tested T3.5 Serial1-6

T3.6 - Added support for LPUART which is Serial6 which now works.

T-LC
Make half duplex work on T-LC on Serials1-3

Tested on on T3.5 1-6

Was using SEREMU_TX_SIZE should use RAWHID_TX_SIZE

Like what was added for T3.x with that 3 yeard PR, I added the same support to T4.x

Added the PORT TOGGLE defines.  I copied the _PORTSET blocks and then simply used block editing in Sublime text to then change the SET to Toggle.

Also added in the code...

Test sketch:
```
void setup() {
  pinMode(13, OUTPUT);
}

int led = 13;
void loop() {
  digitalToggleFast(led);
  delay(500);
  digitalToggleFast(13);
  delay(250);
  digitalToggle(13);
  delay(1000);
  digitalToggle(led);
  delay(250);
}
```
Also added values to keywords.txt

https://forum.pjrc.com/threads/61412

The code for T3.x was broken, especially for USB2...

And the code was not setup for T4.x.  So added it.

I forgot to remove the default eventhandlers from some of the HardwareSerial files as such the ones in the serialEventX files was not used and why my flags were not set properly.

Could have done simple fix, but decide to make it more consistent with what I did in T3.x/LC code and not look through all the NULLS, but simply have list of active ones and count of active.

Appears to fix the issue so far.

Found a way that appears to work to detect if a sketch has our default serialEvantX functions, and that the users code has not implemented their own.  Before on SerialX.begin() I would add that serial ports code to table of function calls to do the if SerialX.available() call serialEvernt..

But I now have a hacked up version where each of the event functions are in their own source file, along with a variable that is defined.  Elsewhere I have those same variables defined with an attribute of ((weak)), so if our default implemention is pulled in it is defined with a value of 1, if the weak version is used because the user has their own implemention, then  it is defined as a 0... So I can detect this at the begin method and only add the code to do the checks in yield if the user implemented it.

WARNING this also brought in changes for using XBar pins for CTS and RX pins... As I did not wish to split back out and have you maybe have to manually merge.

Looks like the macro was defined with a space instead of an underscore, breaking the intended macro name.