sdl: safer code to resolve intermittent controller crashes related to disconnections

[xTVaser]

Related to #2752

I had to try really hard to reproduce this (constantly unplugging and plugging in my controller). But this seems to happen for a variety of reasons (i got an DirectX error on the SDL_GameControllerOpen call one time), now any issue in the original initialization will result in the controller being skipped and picked up on the next reconnect (hopefully).

This may introduce a bug where controllers that legitimately have no name are ignored. To work around this, a call to SDL_GameControllerGetAttached may be needed to differentiate between a bad device handle and a nameless controller.
Nope, controllers in this state return true for being "attached and valid":

Also I was able to reproduce the LED crash, hopefully checking the handle is sufficient to stave that off, but it might be a bug internally in SDL (because it should just be returning -1, not crashing somewhere).

[xTVaser]

Isolated code that touches SDL directly which is called from the EE. After fixing the errors in the initialization of a GameController:

• Noticed that anytime SDL_GameControllerName was null the guid was also empty
• This let me revert the change to SDL_GameControllerName so that if NULL is returned (which is valid, aka no string) it will default to "" again.

I was still getting crashes related to the LED though. My theory is that while the EE thread is hammering these SDL functions every frame to do things like update the LED or the vibration -- the other thread is trying to handle the event that the controller has disconnected and tear it down. By isolating that code to run after all SDL events have been processed for that frame, this should make things more consistent. In my testing I unplugged/plugged in my controller for a few minutes straight with no crashes