My quigg

I have removed the footerlength definition from protocol.h and quigg_switch.c and use with this commit the original daemon.c code, although this has a significant impact on performance with regard to the number of data packets required by pilight to accept data packets from an original GT-7000 handheld controller (with footerlength and the modified daemon.c code pilight is as fast as a real device, with the pilight code the device will react and pilight will not report any data as valid). Thus I still do not agree that the addition of footer packets by using the function "protocol_plslen_add" is the best approach.
I have an GT7008AS switch on order, thus the dimm code is not yet tested but I will ask RinusW to get it checked out (as it is required for the GT-7008AS), the way the dimm parameter is implemented with this pull request is now the same as it is handled by the GT-7000 remote controller.

I am currently struggling with the documentation regarding adding new protocols, it seems that the chapter 5 and 6 in the documentation "http://www.pilight.org/development/protocols/":

-----

5. Edit the pilight.h.in file and add the following content definition:
#cmakedefine PROTOCOL_DUMMY
6. Edit the libs/pilight/protocols.c and add the following at the end of the includes list: 

----

needs to be revised, as those locations and files seem to be moved to another location with V5.0
I assume that this is in combination with the request for removing the sending part all together.
I am hesitant to do this due to the following reason:
In automation and control jobs, you face quite often the task to modify an existing control application, but you have no access to that application but the sensor data only. Thus you want to get in the middle of sensor and existing controller, The existing control application expects the data in the original format, thus i have added sending capabilities in order to be able to emulate a real device.