Add ESP32-S2 and ESP32-S3 support

[joelsernamoreno]

This PR adds explicit support for ESP32-S2 and ESP32-S3 variants, which were previously not detected correctly because they do not define the ESP32 macro used by the generic ESP32 block.

Changes:

• avrpins.h: Added dedicated blocks for ARDUINO_ESP32S2_DEV / CONFIG_IDF_TARGET_ESP32S2 and ARDUINO_ESP32S3_DEV / CONFIG_IDF_TARGET_ESP32S3, each with the required pgm_read_* workarounds and pin definitions. Both variants share the same default SPI2 (FSPI) pins: GPIO12 (SCK), GPIO11 (MOSI), GPIO13 (MISO), GPIO10 (SS), GPIO14 (INT).
• UsbCore.h: Added MAX3421E typedef entries for ESP32-S2 and ESP32-S3.
• usbhost.h: Added SPi typedef entries for ESP32-S2 and ESP32-S3.

Note on SPI initialization:
Unlike the standard ESP32, the ESP32-S2 and ESP32-S3 require explicit SPI bus initialization in the sketch before calling Usb.Init(). Without this, the SPI bus will not be configured correctly and the USB host controller will fail to initialize:

SPI.begin(12, 13, 11, 10); // SCK, MISO, MOSI, SS

This has been tested and confirmed working on ESP32-S2.

[xxxajk]

Ever thought of just using UHS3? if not, why not? Technically UHS2 is targeted at weaker MCUs that typically don't have USB. UHS3 is designed so it won't collide with board supported USB, or other libraries. The only thing you would need to do is get it to cooperate with the S3, which is to make the RAM access in an ISR safe.

This PR would break a lot of software that people have written over the years too, due to the way a lot of people interface with this library.

[PaulStoffregen]

if not, why not?

People's opinions of UHS3 might be influenced by readme words like "Pre-release" and "No technical support" and "EXTREMELY ALPHA!" The few words that indicate anything works cite ancient versions of Arduino IDE. Compare with the presentation on version 2, which has a photograph of hardware, lots of links and info, and a long list of "Currently the following boards are supported by the library".

But for people who discover Arduino libraries using Library Manager in Arduino IDE, consider what they see with a search for "usb host shield". They never even get to the unwelcoming readme because as far as Library Manager is concerned, UHS3 doesn't exist.

[xxxajk]

if not, why not?

People's opinions of UHS3 might be influenced by readme words like "Pre-release" and "No technical support" and "EXTREMELY ALPHA!" The few words that indicate anything works cite ancient versions of Arduino IDE. Compare with the presentation on version 2, which has a photograph of hardware, lots of links and info, and a long list of "Currently the following boards are supported by the library".

But for people who discover Arduino libraries using Library Manager in Arduino IDE, consider what they see with a search for "usb host shield". They never even get to the unwelcoming readme because as far as Library Manager is concerned, UHS3 doesn't exist.

Absolutely true. Do I use UHS3? Yes, I use it on the better/larger chips.
Technically UHS3 is "better" because it doesn't try to do things that crash some USB devices that have specific quirks, partly thanks to microsoft writing bad drivers in 1995, which ended up becoming part of the spec, and partly due to lots of device makers not getting things correct, only correct enough to just pass a test suite that doesn't hit the corner cases. USB is a frustrating mess, always has been. When moving such a heavy lift to an MCU, the usual compromise is to limit the options, which sacrifices compatibility.

One thing it really lacks also is that some MCU's have strange issues that I never fully worked out, such as on the MK20's USB, where it can't get access to RAM quickly enough, no matter where I place the buffers, causing DMA timeouts from the IP in the chip. It can get quite frustrating.