Add uv_device_t as stream on windows and linux, handle device I/O asyncly.

I'm a multi-language programmer, but not family with english, so maybe trouble with options. libuv is a good i/o framework, and easy to extent, I hope persist on it to do my work.

When I want to do r/w device on windows, I try filesystem api, it works for device handle, but not fit my needs. I need a real stream, I try wrap handle as pipe, and fail to work. When I study TTY and TCP, I realize that it not hard to implication a device type stream, because just file operation with overlapped,  even simpler than other stream types.
When I finish my job on windows, i realize libUV is born for linux, simple to add a device type, so i did it.

There are only three type related api.

```c
UV_EXTERN int uv_device_init(uv_loop_t* handle, uv_device_t* device);
UV_EXTERN int uv_device_open(uv_loop_t* handle, uv_device_t* device, const char* path, int flags);
UV_EXTERN int uv_device_ioctl(uv_device_t* device, int cmd, void* arg);
```
uv_device_open create a uv_deive_t, path should be '/dev/??' on linux or "\\.\Global\???" on windows.
flags should be  O_RDONLY,O_WRONLY  or O_RDWR.

uv_device_ioctl will set or get device paramater,  arg is relative with OS platform. on windows please use are uv_ioargs_t, detail please see header file.

because not test widely, so maybe have bugs, please attention.

Happy for do something for libUV.
> This should preserve the contents of handle->data.

@bnoordhuis: uv_loop_init does not preserve it, FWIW. I don't mind either way, but if the handle initialization fails what's the point of storing anything in its data field? Whichever we choose we should add some explanation in the docs, I think.