Hardware modes are now modular

Previously the gpio and module hardware modes where hardcoded inside
the daemon, learner, and debugger. This made it difficult for
developers to add support for additional external hardware. This
commit makes the hardware support modular just like the protocols
are. The currently supported hardware types are now exported to this
new structure and can be found in the "hardwares" folder.

The immediate advantage of this abstraction that is the lirc lib has
become obsolete. To use the kernel module, only the bare minimum of
code is now used to read from and write to the kernel module, making
pilight less bloated and faster.

Another important change is that the learner and debugger now use
the main settings.json file to know what type of hardware is used
to receive codes from. So, they don't work independently anymore.
Forgot to activate the "none" hw-mode
Small error in Makefile
Added repeat counter for received codes

1) The intertechno dimmers have their dimlevel set by the amount
of repeated codes sent. So to successfully recieve the intertechno
dimlevel, we must know how many codes were recieved. With this commit
the number a specific code was in a sequence of received codes is
communicated to the protocols' parseCode and parseBinary function.
2) It was also time again to remove all trailing and thereby useless
white spaces.
Multiple ID support and All support, and fixed relay bug

1) This commit adds support for multiple ID's per device. Check
the README.md on how this new syntax looks.
2) This commit also adds support for the All function of certain
protocols. The config lib will now match only those ID's that are
communicated by the protocol. In case of the All function of
the arctech protocol, only the "id" matters, so the "unit"
isn't communicated. The config will then search all devices
matching only this "id" value and change it's state. When both
the "id" and "unit" are communicated only those devices matching
both will get updated. Just like the actual devices.
3) This commit also fixes a small bug in the relay protocol in
which the currently used hardware mode wasn't correctly
identified and thereby incorrectly complaining about reservated
gpio pins.
Update README.md
This commit allows changing protocol specific settings

1) Small uninitialized message was fixed in the module hardware.
2) Alignment errors in the webgui weather module where fixed.
3) Every protocol can now have specific settings that can alter
it's behavior. E.g. some dimmers can have 15 dimlevels, others
can have 8. Some weather stations communicate in 2 decimals
some with none. Etc. These settings can now be set inside each
protocol and when necessary be overriden by the user in the
config.json file. Check the wiki for protocol specific settings.
4) The webgui has been adapter so it's modularly adapts itself
to the protocol specific settings.
5) The daemon now differentiates between internal communicated
config settings and external settings. The "type" and "order"
settings will now only be used internally so there is no need
to set them inside the config.json. Also, only the overriden
protocol specific settings will be stored in the config.json.
This makes the config.json less bloated.
Merge branch 'development' of https://github.com/pilight/pilight into development
Updated README.md with new features
Allow (non-blocking) pilight-send call from within process-file.

Previously, calling the process-file was a blocking action. Thereby
a subsequent pilight-send call wasn't possible. In the new code
the process-file is ran inside a thread so it will be non-blocking
allowing a subsequent pilight-send call.
Added generic switch and dimmer protocol
Add version and current commit to log
Better info messages from daemon
Reimplemented protocol specific settings functionality
Added protocol readonly setting
Added protocol settings sanity check
Added whitelist setting for socket connections
This commit fixes the "none" hw-mode and various small issues

1) The none hardware mode didn't let the daemon run in a loop
2) The new whitelist socket function now contains comments
3) Various valgrind "still reachable" issues where resolved
Fixed webserver redirect at default daemon port
Update README.md