usb: rename usb_drv_recv() to usb_recv_recv_nonblocking()

IMHO the current name is somewhat misleading:

- usb_drv_send() is blocking and we have usb_drv_send_nonblocking()
  for the non-blocking case. This inconsistent naming can only
  promote confusion. (And what would we call a blocking receive?)

- Other hardware abstraction APIs in Rockbox are usually blocking:
  storage, LCD, backlight, audio... in other words, blocking is the
  default expected behavior, with non-blocking calls being a rarity.

Change-Id: I05b41088d09eab582697674f4f06fdca0c8950af

firmware/target/arm/tms320dm320/sansa-connect/tnetv105_usb_drv.c

@@ -1026,8 +1026,8 @@ static bool tnetv_handle_cppi(void)
     if (rx_intstatus || tx_intstatus || rcv_sched)
     {
         /* Request calling again after short delay
-         * Needed when for example when OUT endpoint has pending
-         * data but the USB task did not call usb_drv_recv() yet.
+         * Needed when for example when OUT endpoint has pending data
+         * but the USB task did not call usb_drv_recv_nonblocking() yet.
          */
         return true;
     }
@@ -1371,7 +1371,7 @@ int usb_drv_send_nonblocking(int endpoint, void* ptr, int length)
     return _usb_drv_send(endpoint, ptr, length, false);
 }
 
-int usb_drv_recv(int endpoint, void* ptr, int length)
+int usb_drv_recv_nonblocking(int endpoint, void* ptr, int length)
 {
     int epn = EP_NUM(endpoint);
     struct ep_runtime_t *ep;
@@ -1388,8 +1388,6 @@ int usb_drv_recv(int endpoint, void* ptr, int length)
     return 0;
 }
 
-void usb_drv_ack(struct usb_ctrlrequest* req);
-
 void usb_drv_set_address(int address)
 {
     UsbCtrlType usbCtrl;