boot-cypress: Fix lingering rejected control transfer

This is equivalent to the following change in glasgow firmware:
GlasgowEmbedded/glasgow#660

In boot-cypress this was triggered if I did the following:
- `python3 -m fx2.fx2tool read_eeprom -f filename.bin 0 32768`
  - result: `Command timeout (bootloader not loaded?)`
- `python3 -m fx2.fx2tool load boot-cypress.ihex`
- `python3 -m fx2.fx2tool read_eeprom -f filename.bin 0 32768`
  - result: `Command not acknowledged (wrong address width?)`

This sometimes even resulted in total corruption of the flash
memory, and should be fixed since it's an easy mistake to make.

This happened, because while there was no firmware loaded, the
SUDAV interrupt is sticky. When the bootloader firmware is loaded
It immediately tries to process a setup packet. But in the
endpoint buffer it actually sees the control transfer that
took the CPU out of reset, and it doesn't know what to do with it,
so it falls through to the EP0_STALL. From this point on the
same thing happens as in glasgow firmware: The rejected control
transfer is retried again and again. And it is retired again and
again while the EP0 buffer is getting gradually filled with a new
control transfer that has not arrived yet. So the CPU will see a
mix of the old control transfer and the new control transfer,
which will result in data corruption.

Author: purdeaandrei

firmware/boot-cypress/main.c

@@ -191,6 +191,7 @@ void handle_pending_usb_setup(void) {
     return;
   }
 
+  pending_setup = false;
   STALL_EP0();
 }