Generalize handling of extension devices

Since my request for discussion of this topic on the mailing list was not as fruitful as I hoped, I figured it would be best to just whip up a basic implementation of a more flexible EXT handling.

This has no fancy plugin-like interface and I am not sure we need that. The downside is that the application is completely responsible for interpreting the unprocessed data that it is handed by the lib. It would probably be nice to wrap this in some kind of EXT module of the lib, at least for the offical extension devices (currently only Sharp Shooter and Racing Wheel, at the moment of writing).
There are a couple of functions that require the caller to free the returned buffer, `psmove_get_serial()` among them. They all return strings.

Avoiding the repeated allocation makes sense. But instead of managing the buffer inside PSMove, we could change the interface to require a pointer to a user-allocated `PSMove_Ext_Device_Info`. This is what I did with `psmove_get_ext_data()`, and to be honest, I do not remember why I did it differently for `psmove_get_ext_device_info()`. Do you see anything wrong with this alternative to managing the buffer inside PSMove as you suggested?

Just as a note: Calling `psmove_get_ext_device_info()` can return different contents on each call. So, unlike `psmove_get_serial()` the first result cannot even be cached internally but *always* needs to be retrieved from the controller.