Introduce test to identify datetime issue
Allow 'add' to throw if datetime out of range
Change type of thrown exception to ArgumentOutOfRange
Consolidate tests and improve coverage
Add tests to check maxvalue range

This exposes another bug which involves our handling of DateTimes
that have an "Unspecified" DateTimeKind.
Treat 'Unspecified' DateTimeKinds as UTC.
Store datetime as string if unable to store as edm datetime
Move table storage limit values internally

These are no longer relevant to a user.
Serialize DateTimeOffset values as string if out of range
Throw InvalidOperationException if we cannot parse date
Add assertions to tests
Use equality checks instead of IsTrue
Rethrow table storage IOE if we cant handle it
Use a DT -> string serialization format with more precision
Update to Storage 2.0.6
Add minvalue test

We now have tests covering min value, max value, and an
arbitrary value that isnt a valid edm datetime
Switch on edm type instead of using exceptions
"Handle" emulator quirk by informing the user about it
Merge pull request #75 from jkling/HandleDateTimeRanges

Handle C#/Azure DateTime range differences