Initial commit

The file watcher is ready.
Adding a file keeper to track the life cycle of all files inside the
file_keeper dir.
During the startup the file_keeper program will check if there is a dir
called file_keeper at the user's home dir, if not it will create for us.
This program uses git to handle the file's content changes. For each
file inside the file_keeper dir it will be created a dir inside file_keeper/.db
with the exactly same name of the file present in the file_keeper dir file name present at file_keeper and a git repo will be initialized in it. This git repo will be responsible to track all the changes for a file, so the user can easily
go back in time and recover exactly what he/she wants.
Bug fix: g_file_monitor_directory() does not track individual file changes,
we should add a monitor for each file present in the file_keeper dir.
As a reminder we should ignore the changes that have been made at
file_keeper/.db
Bug fix: Now the file keeper is able to handle file deletions.

If a watched file is deleted, we must delete its hard link as well and
commit the change set. However as simple as it sounds, I had to change
the way that the file_keeper.c fetch the file name. It's impossible to
use g_file_quer_info() to fetch the file's name, since the file
does not exist anymore. I fixed this problem by adding a function
that returns the file name based on its path.
Scheduling file changes.
Do not commit the changes immediately, probably the file will be changed
again. Doing this way we avoid doing a lot of IO operations and the
commits will decrease drastically.
Only commit the files if their content changed. If access time,
or some other attribute changes we should ignore it.
Fixing memory leak.

If the file is already scheduled to be commit we were leaking the
file path, because we will not create a new file changed info and
then leaving leak the path.

To avoid the leak _file_watcher_monitor_changed() must always free
the file path and _file_watcher_file_changed_info_new() will
dup the path passed as argument
Stop using file paths as hash keys, use file's hash instead

Reasons
* Memory saving - We won't need to keep a duped string.
* It's faster, comparing integers is much faster than strings.
If any changes are made while the file_keeper is not running,
the next time it goes up we should commit those changes.
Be safe, info can be NULL
Bug fix: Handling binary files editing.

When a binary file is edited and saved the GFileMonitor reports that
the operation type is G_FILE_MONITOR_EVENT_DELETED, makig us belive
that the file was deleted. However the file may still be there, so
to properly handle binary file changes we must check if the file
was really deleted, because if it was not we should register another
monitor to it, recreate the hard link and commit the changes!
Bug fix: Stop rescheduling the timer, because in some scenarios
the timeout may never happen!

Imagine a case where constant file changes are being made in the
file keeper's dir, with the old logic we were always rescheduling the
timer, delaying its execution. If we create an program that won't
stop to write in the file kepeer's dir the timeout would never expire
and the changes would never be saved. From now on only create the timer
if the previous one has expired!
Bug fix: Avoid overflow and use the correct macro ! (file hashs are guints)
Make it faster !

Avoid list usage for search, this list can be pretty big.

Also i removed that comment /* Don't even start */ and the code bellow it,
because the list (now the hash) can be empty at the program startup.
This case can be consired that all files were deleted from the file
keeper's root dir
Explicitly cancel the monitor watch using g_file_monitor_cancel().

If the monitor is deleted without calling this fuction the program may
segfault in a very specific case. When the user is editing the same binary
file constantly, a lot of "delete" events will happen and we will delete the monitor and create a new one. After some time we will stop receiving file change
notification and the program will segfault at glib level.

The curious thing is, I supposed that when a GFileMonitor is deleted
it should cancel its monitoring file by itself. Strange....
Bug fix: Chaging the rule to add File_Changed_Info to the _changed_files list.

There was a problem when the user edited a file and right before he
deleted the file. We would not insert a new changed file info because
the list _changed_files already has an entry with that hash, however
this entry is not marked as deleted and the file keeper will try to
commit files changes and it will fail, since the file does not exist anymore.
This patch addresses this kind of problem.
Only create the timer if the list is not empty.
Adding Windows dependent function for hard links
Adding a git ignore
Adding the readme file