Issue #3002583 by Mike Lewis, joelpittet, coredumperror: Illegal string offsets in rdf.module in PHP 7

This reverts commit d7a1693d.

Issue #2709557: X-PROPERTIES now import properly when added via hook_date_ical_mapping_sources_alter.

Issue #2267721 by John Franklin: Add Taxonomy Term and Node Reference support to the iCal Entity Views plugin LOCATION field

When I wrote up a fix for one of the changes made in the newest version of Feeds,
I put the fix a few lines after it should have gone. This resulted in blank
RRULEs going undetected when those versions of Feeds are installed, making the
parsing code attempt to parse a blank string, which threw warnings and notices.

I'm a complete idiot, and totally failed to test the iCal import functionality
with iCalcreator v2.22. Turns out, the author made much more significant changes
to the library than I'd thought, and those changes completely broke the import
process. With several hours of work, I could probably re-write Date iCal to
support these changes, but those re-writes would necessarily make Date iCal
incompatible with v2.20.2 of the library, which would break every existing Date
iCal install the next time they update, unless they also update iCalcreator.

Thus, due to my lack of available time, and the update incompatibility problem,
I'm just declaring that Date iCal 7.x will not support iCalcreator v2.22, ever.
If someone comes along to make a Drupal 8 version, they could choose to put in
the time to re-write the guts of the import code to make it v2.22-compatible.

I'm not sure what changed to make the old code stop working (updates to the
Date module, perhaps?), but it was definitely not rendering RDATE and EXDATE
properties correctly. Sadly, RDATEs are still broken in all Apple-based calendar
apps, but that's their fault.

I used to like keeping whitespace on blank lines that lined up with the
indentiation level of the code. I don't like doing that any more, so out it goes.

I was very sleepy when I applied this patch, and didn't think through what it
was doing. The user who submitted it was actually just using Address Field wrong.

Thanks go to user pc-wurm for discovering this bug. Being in the United States,
I hadn't noticed that "US" was actually the country code, rather than the
country name, which is what Date iCal should have been rendering into the
LOCATION field.

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.