visomat-data-downloader: increase the eeprom buffer size

Apparently the device can store up to 60 records per user, for 2 users,
and each record is 20 bytes.

Considering that the data has some header info like:

  M160...M260...

the buffer must be at least:

 (20 * 60 * 2) + 8 + 2  = 2410 bytes

Finally, the extra 2 bytes are the STX and ETX bytes.

Increase the buffer size to 4096 bytes to be safe.

Thanks-to: Cornelis Broeders <cornelis.broeders@web.de>

visomat-data-downloader: use a symbolic constant for the packet size

visomat-data-downloader: dump the eeprom in any case after get_response()

visomat-data-downloader: add an option to enable libusb debug output

visomat-data-downloader: add some debug facilities

visomat-data-downloader: more precise data validation in decode_eeprom()

visomat-data-downloader: use uint8_t for bytes

Makefile: don't use clang unsupported options with clang

visomat-data-downloader: fix a missing parenthesis in an output string

visomat-data-downloader: fix format strings

contrib/visomat.gnuplot: improve plotting data for both users

Fix parsing the eeprom when there are users with no records

When the number of records for a given user is 0, there is a dummy byte
at the end of the user memory block which has to be consumed as well,
otherwise the while loop never ends.

The bug was found out by Cornelis Broeders <cornelis.broeders@web.de>

Improve a comment in visomat-data-downloader.c

Wrap line exceeding 80 characters

Set configuration following libusb.sourceforge.net/api-1.0/caveats.html

Improve error messages relative to libusb calls failures

Misc libusb cleanups

Use symbolic constants, check return values, auto detach the kernel
driver, release the interface.

Fix a typo

Handle time of day in the gnuplot script

Add a way to filter measurements by user ids

Fix parsing systolic pressure

There is another field between the time and the systolic pressure, it is
still not 100% clear what it means, it could be an indicator for
arrhythmia.

Claim interface after detaching it from a possible kernel driver

This avoids error messages like:
  usbfs: process 24665 (myprogram) did not claim interface 1 before use

See also:
  http://stackoverflow.com/questions/11088691

Add more info about the communication protocol

Add a .gitignore file

Initial import