Add -fdata-sections to itemize RAM usage in linker map
Add a build.zip target
Ask Travis to make the build.zip target
Upload build.zip to flysight-ci app
Merge pull request #19 from willglynn/travis_to_flysight_ci

Push build artifacts from Travis to flysight-ci app
Merge pull request #20 from willglynn/data_sections

Add -fdata-sections to itemize RAM usage in linker map
Generate a signature file on boot

Currently, FlySight devices can be recognized by inspecting their USB
IDs. This changeset causes the FlySight to automatically generate a
FLYSIGHT.TXT file containing a unique identifier. This allows simple,
user-level tools to identify that a) a newly-mounted volume contains
FlySight data, and b) this data was generated by a specific unit.
Zero-parameter methods need (void)
Move version into FLYSIGHT_VERSION define

This is #defined from the Makefile by passing in a -D compiler option.
The version is generated automatically using `git describe`, the output
of which uniquely identifies the commit. Additionally, the output can
be made more readable (i.e. humanized) by using tags.

Changing the firmware version no longer involves updating any files; it
merely requires committing and building. As a result, Version.h must
always be considered "dirty" by the build system, and any referencing
code must be rebuilt. Recompilation could be reduced by defining
FlysightVersion as an extern char[] PROGMEM, but this is slightly less
convenient for the calling code, so I decided to go this route.

This can be made to work on Windows using batch files, but I do not have
a suitable development environment at this time.
Write FLYSIGHT_VERSION into flysight.txt

This makes it very easy to determine exactly which build is installed
on a FlySight. Additionally, due to the increased verbosity of the new
version string, one may revisit the corresponding source tree by running
`git checkout {version}`.