Add support for R.A.T.TE

@eyal0803 reported that his R.A.T mouse was not supported.

It looks like MadCatz is producing a whole lot of new mice, and the protocol might have changed a bit, so it needs to be investigated.

From the initial report (at #4 ), the IDs are:

{'vid': 0x0738, 'pid': 0x1704, 'name': 'R.A.T TE'}

However, an exception is raised in

measure = self.handle.controlRead(self.ctrl_request_type,
                                  self.ctrl_request,
                                  self.ctrl_value,
                                  self.ctrl_index,
                                  self.ctrl_length)

Which is later caught, but makes the function return some invalid data, that causes a crash.

Here is the crash backtrace:

Found one device: {'pid': 5892, 'name': 'R.A.T TE', 'vid': 1848}
Traceback (most recent call last):
  File "./ratctl.py", line 402, in <module>
    main()
  File "./ratctl.py", line 392, in main
    w = MainWindow()
  File "./ratctl.py", line 378, in __init__
    self.data = Data(self.pbar, self.tabs, self.dpi, self.com)
  File "./ratctl.py", line 227, in __init__
    self.pool()
  File "./ratctl.py", line 230, in pool
    self.dpiMode = self.com.getDpiMode()
  File "./ratctl.py", line 152, in getDpiMode
    return mode[0] / 16
TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'

The problem is twofold here: we need to support the mouse, but also fix the subsequent crash, and provide a helpful message in case it happens.

@eyal0803, I have seen the same kind of error with the first version of the tool, when the driver didn't have the right permissions to access the device. It should now write an informative message; but could you check that this isn't a permission issue? (ie, did you write an udev rule or launch it with sudo)?
Otherwise, the protocol probably changed. Would it be a possibility to capture new packets? A windows VM with the official software and Wireshark would be needed (it can also be performed directly on Windows). I can help you doing it, or I can perform it remotely if necessary.

We need to ensure that the protocol stayed the same, so we can either re-capture the packets, or try to send the old ones and see what sticks. THe former method is more complex, but that will be needed anyway if the protocol changed.

Writing a guide might not be a bad idea; as some people will want other functionality not yet in the driver: RGB LEDs, etc... And if they provide the protocol information themselves, that would speed things up.

Start in ratctl.py at Data.pool, getDpiMode, and the controlRead call, then verify whether the failure is caused by permissions or a changed R.A.T TE protocol. Use the reported device IDs and, if needed, recapture packets with the official software. Done means the R.A.T TE is supported, failures return a helpful message, and invalid data no longer causes the crash.