Issue when using stalls in vendor-defined control transfers outside of the interrupt context

[nwright98]

This was seen in a vendor-defined application on an ATSAME51G19A running FreeRTOS.

USB transfers stop working when a bus stall is used to indicate an error in vendor-defined control transfers and is called outside of the interrupt context (deferred handling.) I traced this to the following reasons:

1. DRV_USBFSV1_DEVICE_EndpointStall() calls _DRV_USBFSV1_DEVICE_IRPQueueFlush(), but when called outside of the interrupt context a new read IRP does not get submitted for endpoint 0, so new control transfers are never received. I was able to work around this by not calling _DRV_USBFSV1_DEVICE_IRPQueueFlush() if hDriver->isInInterruptContext is true.
2. _USB_DEVICE_Ep0ReceiveCompleteCallback() is called on completion of the stall, which subsequently calls the application callback function. This calls driver functions which attempt to make nested calls to lock hDriver->mutexID resulting in a deadlock. This may work if recursive mutexes are enabled, but I worked around by returning immediately from _USB_DEVICE_Ep0ReceiveCompleteCallback() if (irpHandle->status == USB_DEVICE_IRP_STATUS_ABORTED) || (irpHandle->status == USB_DEVICE_IRP_STATUS_ABORTED_ENDPOINT_HALT).