Resolves https://github.com/arduino/Arduino/issues/3675

This also saves us tons of flash and ram for the Leonardo if the CDC Serial/HID is not used.
Example: 3724 flash, 135 ram (with Serial.begin(0)) vs 578 flash, 9 ram without

void setup() { Serial.begin(0); }
void loop() {}

The "downside" is that you need to reset the Leonardo if no USB-Core was compiled. But with the new Serial touch waiting this is not a problem. Maybe an additional note like "If your Leonardo board does not show up, reset it NOW." could easily solve this.

This PR would save us a lot of flash + ram AND USB caused problems (like unneded time consuming USB ISR Interrupts).

Edit: I updated the PR this way:

• For the current bootloader everything is the same as before
• For newer bootloaders (with the BOOTKEY fix) the USB-Core will only be included if its needed.
• This way we can avoid any USB Clock workaround which would add more not wanted bytes.

The positive thing is that newer bootloaders are more save (Bootkey position, all registers cleared) and compile smaller (with this PR). And if the old bootloader is used nothing changes.

Only for newer bootloader

There is also a problem that if no USB-Core is used, the Led blink example wont work correctly with the current bootloader. This is caused by a bad coded bootloader which does not fully reset the MCU via watchdog and leaves the USB-Clock configured. You need a workaround to fix this (not included in this PR yet). HoodLoader2 already includes this (if you want to see it in action, v2.0.5 available for 32u4 as well!).

The Workaround is not so easy to add in this flexible setup. In my case I let the user choose with/without USB-Core. Thatswhy I only enabled it for fixed bootloaders to avoid flash consuming workarounds. So old bootloaders still work, but newer can use this feature.

Updating the bootloader can fix:

• This PR
• Magic Bootkey Critical Leonardo + Micro Bootkey conflicts #2474
• Change the reset behavior similar to this (but with different implementation)
• Maybe also include the Fast USB-Serial if you like to from HoodLoader2.

So a new bootloader would really solve some issues and makes sense to me. Especially clearing all registers via watchdog and using a proper BOOTKEY position can solve unexpected problems. (if you code a new bootloader make sure to use the lufa master, since it contains an important USB-HUB fix.)

You then could provide a simple bootloader burning sketch to flash the new bootloader with a 2nd arduino (to avoid confusing about ISP, capacitor etc).

Questions

• This PR used the weak setupUSB() function. It was not used as far as I see. Is there any reason?
• Do I need to declare a prototype of the setupUSB() in USBAPI.h again or does this cause more problems because of the weak definition in main.cpp?

cc @facchinm