Had wrong pin in my table, so fixed table.

User found on forum: https://forum.pjrc.com/threads/58414-Teensy-4-0-Serial3-attachCts-wrong-pin-in-HardwareSerial3-cpp?p=221464#post221464

Here is a first pass at trying to get the AVR emulation of Ports working like it did for T3.x.

Not 100% confident, but at least simple sketch is working.

Needed to implement Quad encoder library.

Current naming is confusing since it differs between GTP1 and GTP2. The GTP2 version is compatible to the naming in the data sheet. So I suggest to adjust the naming for  GPT1

As per the Teensyduino 1.48 release thread.

T3.x sketches could compile that had int mai() {} and not void() and setup():

So simply copied over setup.cpp from T3 folder of cores, and then changed setup.c to call main, which simply calls setup and loops calling loop/yield.

Added another endless loop after the call to main() to hang there if the users main returns.

Tested with simple sketch
```
#include <arduino.h>
int main (void) {
  pinMode(13, OUTPUT);
  for(;;) {
    digitalWriteFast(13, HIGH);
    delay(250);
    digitalWriteFast(13, LOW);
    delay(250);
  }
}
```
tried it on T3.6 verified before compile failed and now works.  Also compiled and run a normal app to just make sure it was not totally busted

fixes #394

https://forum.pjrc.com/threads/57360-Teensy4-IntervalTimer-Channels-Problem

I suggest to explicitely delcare a (say)  IMXRT_TMR_CH_t struct which collects the registers for a TMR  channel instead of implicitely defining this struct in the declaration of IMXRT_TMR_t.

This would allow for an easier definition of user classes modelling a TMR channel.
Not a big deal, could also do that mayself the class code but it would be more convenient if this would be done in imxrt.h

Edited here on the web - copied to local machine and it built as tested : https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=209959&viewfull=1#post209959

Proposed add locations for  startup_early_hook(); and startup_late_hook(); just before two existing waiting while()'s.
With debug 'PRINT_DEBUG_STUFF' disabled the three T4B2's here hit the EARLY code about 1.2 ms and LATE at about 45.3 ms after the systick is started.

Where the current printf_debug_init() call is might be critical at some point adjust 'something' as you did enabling the Serial4 port for debug - before clocks and other things are started perhaps startup_reset_hook()

The pins were not in the table before...

rx_pins should depend on cnt_rx_pins not cnt_tx_pins, currentlty the same so does not impact

This cut down some timings in yield.

Add quick test at start of function to return if there are no events pending.

Do this before checking if in ISR and the like.  Cut timing down a lot in yield.

Found some of our code has these defined, plus had in another test sketch so defined them hopefully with C bindings, but calls Serial1 object code

Put in probably temporary bandaids to allow code that uses:
Serial.readBytes(Buffer, cnt);

To function.  It simply loops calling the underlying code for Serial.read().

Comment out some of the main programs debug print statements plus add yield call to main loop.

yield can now call SerialEvent.

Put hack in that if the user has not overwritten the SerialEvent function, the weak linked one will turn off calling itself...