Use the "interesting" value from g_file_monitor_source_handle_event() to
decide if we're currently being flooded by a stream of boring events.

The main case here is when one or more files is being written to and the
change events are all being rate-limited in the GFileMonitor frontends.

In that case, we become "bored" with the event stream and add a backoff
timeout.  In the case that it is exactly one large file being written
(which is the common case) then leaving the event in the queue also lets
the kernel perform merging on it, so when we wake up, we will only see
the one event.  Even in the case that the kernel is unable to perform
merging, the context switch overhead will be vastly reduced.

In testing, this cuts down on the number of wake ups during a large file
copy, by a couple orders of magnitude (ie: less than 1% of the number of
wake ups).