Non-strict DateTime parsing

### Problem

We encountered a file from Google that contained a malformed line:

    EXDATE;TZID=America/Los_Angeles:20140812T15

First, I altered the error raised to include the value that couldn't be parsed as this helped locate the line causing the problem, I think that's worth leaving in even if the rest of the change isn't. I can create a separate change with just that in if desired.

As this raises an error the entire file was unable to be parsed. I looked at trying to ignore the event containing the bad line but couldn't work out how to do that with the current parser structure. Therefore, I looked at how the value fields could be made aware whether they were in strict mode or not and therefore perhaps be a bit more accommodating when parsing in non-strict mode.

This led to me passing through `:strict` as a `Symbol`, as anything parsed will be a `String` key and so I don't think it can clash, and then allowing `DateTime` to be more lenient in its parsing if that is set as false. This then gets deleted in the `super` constructor so it doesn't propagate beyond the initial parsing. If this is an acceptable approach it might be better to add a separate `options` hash to every `Value` for this sort of thing but I thought that would make this PR less clear as to its intent.

I realise that this may not be an acceptable way of working around this problem but I thought opening a PR is better than just opening an issue.

### Change

Allows the time component of a DateTime to be truncated when in non-strict parsing mode.

Also raises a more descriptive error when a DateTime cannot be parsed whether in strict or non-strict mode.