Add Vector can interface.

[sgnes]

support vector can hardware.

[hardbyte]

First thanks for taking the initiative and opening this PR. Before we can consider merging I think we will need to work on this interface a bit further.

I won't merge something that relies on a .pyd file for one particular version of python and windows compiler. For long term maintainability and to be useful to the most people it is important we consider what is the best method for wrapping the vector can dll - and not just take the easiest method. I'll admit my knowledge here is very linux focused, but I'd be looking at the ctypes and ffi libraries.

As you can see on travis we want python-can to be compatible with Python 2.7, 3.4+, and pypy. Ideally for our Windows users we would support 7, 8, 10 in both 32 bit and 64 bit - although I'm not sure if this is the current case for all Windows interfaces. This vectorcan interface would have to also work across most - if not all - of those.

All new interfaces should have decent documentation added to the /docs directory including any custom installation requirements. Ideally each new interface would also have some unit tests, even though most of them won't be able to be run by our free CI.

[hardbyte]

Also a vectorcan interface should support a range of the Vector network interfaces.

[sgnes]

1. This interface support most of the vector can device.

2. Because the dll file which vector original is very hard to use, so I use boost python to easy access to the vector can device, I'm not sure this is the best way to do this?

3. Build a pyd file for python2 and python3, 32-bit and 64-bit, and import the corresponding pyd file for the python environment, is this ok for you?

[christiansandberg]

There is no need to have a compilation step just to interface with a dll. That's what ctypes is for. With just a few lines of code you will be able to use the functions in the dll almost like regular Python functions. Most interfaces except socketcan use ctypes.

You should definitely implement support for extended ids. There is a lot of dead code copied from the PCAN interface so there is some major cleaning up needed.

[hardbyte]

I'm going to close this PR in favor of a ctypes solution.

@sgnes perhaps you could help test and review PR #114?