Save timezone utc date time

Opening this for review as a solution to what was discussed at https://github.com/dimagi/commcare-hq/pull/4386#discussion_r18218758. (Notice I'm PRing into save-timezone.)

This solution introduces a new `datetime` sublcass, `UTCDateTime` that acts like a tz-naive datetime (what we use everywhere) but also keeps track of its "original offset". Compare to a tz-aware datetime:

The current time EST in as a timezone-aware `datetime`:
```python
datetime.datetime(2014, 10, 8, 15, 30, 20, 239874, pytz.FixedOffset(-4 * 60))
```
The same time as a `UTCDateTime`:
```python
UTCDateTime(2014, 10, 8, 19, 30, 20, 239874, original_offset='-04:00')
```

Notes that in the UTCDateTime example, the numbers for hours, minutes, etc. are the values for the UTC time, but the offset is preserved as `original_offset`, to mean "this UTC date was gathered from this timezone".

This lets us treat these objects exactly like we treat the timezone-naive `datetime`s we use everywhere to mean UTC, but without throwing away that information.

`UTCDateTimeProperty` then uses these new `UTCDateTime`s exclusively. It reads in any ISO 8601 datetime, but strictly writes out ISO 8601 unicode datetimes, with microseconds (and the 'Z' ending), followed by a space and the UTC offset string (e.g. '-04:00').

Todo:
- [x] This is obvious, but enable it to read in its own output format (which is not ISO 8601). (I just realized I hadn't done this.)
- [ ] If we like this, fix all the tests to include this utc offset string where necessary

You'll also notice I added a `corehq.ext.unittest` file that contains something I've wanted to be part of our testing library for a long time: a helper for creating "corpus tests" that just compare a bunch of pre-defined inputs and outputs to the real outputs of a function. You can see how these are used with the tests I just added.
> What would you suggest we do about `'2014-10-08'`?

Looks like `datetime.datetime` requires year, month, and day parameters, but defaults hour and minute to 0 if not provided. So I think it's fine to follow that precedent. I also think it's pretty common to use midnight as the default time when dealing with dates in a context where a date and time is required.
```py
>>> import datetime
>>> datetime.datetime(2014, 10, 13)
datetime.datetime(2014, 10, 13, 0, 0)
```
The string representation `YYYY-mm-ddTHH:MM:SS.FFFFFFZ` (ending in Z) makes it explicit that we are treating the lack of timezone as UTC (+00:00). Adding +00:00 is redundant, and therefore gives us a convenient way to show that no timezone is provided without losing information.

> then there's the question of what to do with to_datetime. Do we return a timezone unaware datetime in the case where there was no original timezone given?

Yes. I think that makes sense since the original value had no timezone information.