This delta originated to do the work similar to what was done
for the MIDI code base and support two versions of the object.

All of the code was renamed to a new base class USBSerialBase
which has everything, except the main buffer.

Two sub-classes were made that the only difference is the size of the
buffer to hold all of the USB RX and TX information.

This started off to try to support an FT2232H device which transers
512 bytes at a time instead of what most of our devices were transfering
which is 64 bytes.

While doing this, I found that we have a similar issue with the T4.x
boards which now transfer 512 bytes as well and our Serial object would
not handle it.

So there are two sublasses:
```
USBSerial - for those up to 64 byte transfers
USBSerial_BigBuffer - for up to 512 bytes
```

Note: by default the biguffer version will only handle those
devices > 64 bytes, but you can pass in an optional parameter of the
minimum size, so doing something like:
```
USBSerial_BigBuffer userial(myusb, 1);
```
Will handle all up to 512.

Also the FTDI2232H supports two USB to Serial objects, and our code
was setup that in most cases including when we put in VID:PID pair in
our table, the code would claim would claim
the object at device level so only one USB Serial adapter.

So changed table to support saying for this VID:PID claim at
interface level.  It now works, but not sure for the device I have as
it is a USB to Serial and JTAG and not sure how to test 2nd one.

But while doing this created a test sketch for Multiple Host USB Serial
objects and the two are claimed by this.

I also created a new version of the Teensy USBToSerial example sketch
that if you configure USB type to Dual Serial or Triple Serial will output
SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then
tried T4 configured for Dual plugged
into T4.1 with above sketch and could talk to both USB Serial adapters.

The Claim code was rearranged a lot, so hopefully did not break
anything.

But tested with
T4 as mentioned, both Single and Dual Serial
T3.2  with Single Serial, plus: Serial, Joystick, Keyboard...
FTDI - USB to Serial adapter (Sparkfun)
CP2104 - Adafruit
PL2303 - some clones ...

So hopefully most things are still working

Updated some of the init code for the CP210x.

Before it worked with the one USB to serial adapter I had, but
we foudn it id did not work with Adafruit USB adaptor nor with their metro boards

As per the forum posts, worked on combining the claim code for extracting which endpoints are RX and TX and create the pipes and the like.

Also worked on live cases.  Reading and writing to AX servos... Found some issues Probably more to find.

I left in some debug code to help find cases of deleting a pipe may hang.  Also macros in serial.cpp to set or toggle IO pins (when in debug mode). This helps find where things are happing using Logic Analyzer as a way to find the approriate USB packets.

Did a quick add of support for the Slicon Labs CP210x drivers.  Did similar like messages as FTDI, based on their documents on line:
https://www.silabs.com/documents/public/application-notes/AN571.pdf

This commit adds support for at least some of the Serial boards with the
CH341 chipset, tested using a board from sparkfun as well as one from
Amazon.com

The code was rearranged some of the Claim code and added a VID:DID to Serial Type table that I use to map, such that I know some of these devices have multiple valid setups.

Support Begin/End/Begin - Change baud

Added code to support switching baud rates, or more particular be able to call end() and then call begin(...) with same or different baud rate.

Hopefully some support for also releasing DTR when the end is called.

WIP - Start support for the begin(baud, format)

Adding some support to the code to handle some of the different possible format capabilities.

In particualar trying to handle the parity, number of bits and number of stop bits.

hacked up test app, such that if you type in command line like:
"#9600, 7e1"

It will extract the 9600 as the new baud and try to use format 7e1.  I only hard coded a few of these in the test app (8n1, 7e1, 7e2, 8n2)...

Again work in progress.  Took me awhile tofigure out how to do this for ch341 boards as I did not see any documents or code that handled this.  So had to deduce it from differences in USB packets.

Added support for a another Serial type CH341.

Wip - But I do have it working so far at least with a loop back test (RX shorted to TX)

Also Rearranged some of the Claim code and added a VID:DID to Serial Type table that I use to map, such that I know some of these devices have multiple valid setups.

Will test more.  I have several more cheap USB to serial adapter arriving tomorrow.

Removed some of the #if 1
If defs, plus

cleaned up a few comments

This commit should start to allow some Prolific PL2303 devices to work.
Tis device has a rather more complex initialization process than some
of the other devices.

I have tested this some with one device that I used to use to program
some older RS232 based boards plus talk to an SSC-32 device.
Test case is I am able to talk to SSC-32 and if I type in ver<cr>
It does properly return the version number.

The data I am seeing is pretty close to what
was documented in: https://gist.github.com/tommie/89011c5ac06553d5cdb8
as well as what the Linux driver outputs.

I also incorperated Frank's configuration options.

Have some support in place for the CDCACM serial class code.

It appears to be working for talking to a
Teensy that is programmed USB=Serial
or USB=Serial+...

Also test with an USB2AX board which is a Servo controller for Dynamixel servos (AX-12), that is an Atmega32u2 board programmed using LUFA as the USB library.

instead of having each HUB have 7 buffers, which can eat up space.  We have each main object contribute currently one string buffer, which than when we initialize a Device_t we try to allocate one for it, likewise we release it when the Device is released.

Hopefully less memory needed.

Also updated such that the HIDInput classes can not retrieve these strings.

Changed test program to now also have list of HIDInput objects and when I detect a new one, I again print out info on it...