Read the docstring in the Singleton class for a detailed description
on how it works. I added this class as a meta class to ZWaveObject and
also ZWaveOptions. This should cover all objects created in
python-openzwave that are public.

The deprecated function now handles classes, methods, functions,
properties (get and set together or separate) and variables with any
data type set to it.
A custom message can also be added to the warning that is displayed.

the logging decorators are used for tracking the data path.

the ZWaveOption class is now an instance singleton so there is no need
for this class anymore.

this method is to alter the node reloading when downloading updated
node config files from OZW servers

…n the Windows build)

This is a pretty large thing. There is no longer a need to have the
user install any kind of a module (unless wanting to run the unit tests)

The setup program now handles all deps correctly. It also does not create
a seperate folder in the user site-packages folder for each of the different
python-openzwave modules. They are now all contained into a single .egg folder.
It is not a zip. it is a folder. This makes it easier for the user if
they need to remove python-openzwave manually for some reason. simply delete
the singlke folder and remove the line from easy-install.pth that
pointed to that folder.

Handling of installing the proper event dispatcher is also done internally
It is now all seamless to the user.

The original design was to delete any existing config files blindly
when doing an install. This is not a good thing because if a user has
added any additional files or made any changes to any of the files
it would delete their work with no way to recover them.

The new system I designed makes a backup of the config files then
installs openzwave. then it places the backup back into place. You have
2 options. the first one is you can set the command line switch so the
config files do not get written. Or you can let it do it's update. If
you go with option 2, the program check to see if the file exists already.
if it does it opens both files and check to see if they are the same.
if they are the same it moves on. If not then it checks for the
revision of the file. If the one that is being installed has a higher
revision, the old one is overwritten. if they are the same revision the
program the goes with whichever file is larger. if there is no revision
in either of the files it goes with the larger file.

This is a complicated one. If building and installing python-openzwave
from sources an egg is created. the "factory" version of bdist_wheel
does not create a wheel file that is usable. I wrote a new bdist_wheel
class to handle the packaging of an egg correctly.

Hopefully the last (sigh....)

Removes python 3.4 and 3.3 from the appveyor builds as these seem to
hang without an error being produced. python 3.4 and 3.3 have been
depreciated anywho and it's not worth the time investment to figure out
why it is not working.