usb: dwc3: gadget: Don't start transfer if end transfer was issued

When a request is dequeued, an End Transfer command is sent
although the completion is not immediately sent. However, due to
parallel execution, the controller's event queue may still be
processing an endpoint XferComplete or XferInProgress event, which
may call __dwc3_gadget_kick_transfer() again to start up a new
transfer. Since a previously enqueued request is already on the
started_list, this will simply call Start Transfer on its existing
TRB. If this next request also happens to be dequeued (for example
if a function driver is iterating over its outstanding requests) and
since the previous End Transfer is still pending, it will simply get
given back and unmapped from DMA. Thus the Start Transfer that
was issued after the previous End Transfer will cause the HW to
consume the TRB which will now be pointing to an unmapped buffer.

To fix this, add a check in __dwc3_gadget_kick_transfer() to avoid
issuing any new Start/Update Transfers in case an End Transfer
was previously issued and not completed yet.

Change-Id: I6f86aae0fdfe92b8b7684182c55522522a52f362
Signed-off-by: Jack Pham <jackp@codeaurora.org>