Add in USB code

[ikerperezdelpalomar]

Allow control of the LEDS via USB, so we can remove the test main loop described in #7

• Import from bloodlight-zephyr just the necessary code to run the usb driver.
• Replace libopen USB APIs with Zephyr ones
• Test USB
• Remove test main loop described in Make LEDs work #7

[ikerperezdelpalomar]

Currently USB is working because I managed to get a console via USB in #3.

I believe that the usb.c file configures usb CDC ACM device and it selects between sending data and sending a response to a query (see bl_usb_poll). Since the USB CDC ACM device it's configured by zephyr we only need to adapt bl_usb_poll to zephyr.

I have been looking at the Zephyrs USB stack but I am not yet clear on how to proceeed. So far this are my findings:

• Depending on the use case you might want to use high level APIs or low level APIs. That would depend on the function, e.g. HID uses usb_write/usb_read (low level) and CDC EEM/ECM usb_transfer (high level). My first thought is to use high level apis.
• Looking at usb device controller drivers wiki I understand that I need to:
  0 - Configure a struct usb_ep_cfg_data
  1 - usb_enable(usb_dc_status_callback status_cb)
  2 - usb_transfer_ep_callback(uint8_t ep, enum usb_dc_ep_cb_status_code)
  3 - usb_transfer()

However when asking some doubts about I described above in Zephyrs slack channel I received the next response:

Hello. Is there any reason you are not using standard classes present in zephyr? Does your device require some vendor specific class?
usb_dc_status_callback is something that your application should provide and its used to notify the app about the usb status change. Have a loot into: 
samples/subsys/usb/hid-cdc/src/main.c line: 623 where the usage is shown.

Note that the callback is optional, you can pass NULL as a starting point

unless your application need to trace the usb status, beacause for example it relies on usb a lot

So I am unsure of the way to go here.