Thanks go to d.o user MegaChriz for this fix!

Issue #2482643: Updated README and drush makefile to account for iCalcreator non-backwards compatibility.

iCalcreator v2.22 is not backwards compatible with v2.20.0 and earlier, meaning
it doesn't work with Date iCal.

Many thanks go to d.o user bjlewis2 for pointing that out.

Previously, the time value was pulled from the Date field, rather than the
RDATE field. Now it'll pull from the RDATE field if it has a time, and fall
back on the Date field if RDATE doesn't.

Because the iCal spec states that VFREEBUSY components can't have the
SUMMARY property, Date iCal will now fall back to the COMMENT property
for the node title. Unfortuantely, this is the best we can do, becaise
iCalcreator completely leaves out the SUMMARY property on VFREEBUSY
componeents, so there's no way to recover it.

Thanks go to user mgalman for the patch!

iCalcreator knows that certain iCal properties (e.g. ATTENDEE) can have
multiple entries in a single VEVENT. So when you access ATTENDEE for the
first time, it gives you the first entry. Accessing it a second time gives
back the second entry, or at least it tries to. If there is no second
entry, iCalcreator returns False.

Since Date iCal does not yet support multi-entry properties, I had to work
around this functionality to ensure that hooks which add custom mappings
don't run afoul of this process.

This patch is courtesy of Drupal user cdmo.

Thank you t0xicCode for this patch!

User RedEight pointed out that I messed up the parse regex for UNTIL values
when I made the recent change regarding DATE-type UNTILs. That's fixed, now.

In addition, I tweaked the iCalcreator version detection regex to be a bit
more forgiving of any possible changes the author makes in his version
definition code.

There's a new setting on the "iCal parser" settings page, which lets you set
an integer number of days. Events which ended more than that number of days
before the import will be skipped.

This makes it consistent with the "DateField: Repeat Rule" feeds target
offered by the Date module. It also pushes the source up next to the
"Date: Start" and "Date: End" sources, which helps you find it when you're
setting up your mapping.

This is only a UI change.

According to the iCal spec, the UNTIL value of an RRULE must be specified in
UTC. But certain iCal feed creation tools don't respect this rule, and
instead specify the UNTIL value in local time. Since all the other code that
Date iCal utilizes to parse RRULEs expects the UNTIL value to be in UTC,
this go badly when it's not.

In order to get around this issue, I've added an option to the iCal Parser
settings, which allows users to tell Date iCal that they expect the UNTIL
values in their feeds' RRULEs to not be in UTC. With that option enabled,
Date iCal will treat the UNTIL date as being in the same timezone as the
event's DTSTART.

Upon further research, I discovered that my previous write-up about this
setting was incomplete and partially incorrect. I also discovered the
glaring bugs in the "Date's time zone" setting, so I added a warning against
using it.

Date iCal doesn't currently use this new mechanism (I originally created it
for a feature that ultimately didn't end up needing it), but it may be
helpful in the future for when one handler needs to know about the results
from a previous handler's pass over the same event.

All day events which start on the last day of a month and don't have an end
date specified were broken, due to a silly mistake I made in the DTEND
emulation.

This hook allows modules to alter the final data array for each event,
just before it gets sent through the rest of the Feeds processing steps to
be turned into a node. The context array is what separates this hook's
functionality from what users can do with Feeds Tamper.

Made a few other improvements to the README while I was at it.

By using the amazing, free database of Windows timezone names curtesy of the
CLDR project (http://cldr.unicode.org), I was able to add support for the
non-standard timezone names created by Microsoft Outlook. Hopefully, the
"not a valid timezone" error will now be much less common.