Reimplemented getEqualityFieldValue

I decided to reimplement `getEqualityFieldValue` completely.

This change also makes the field useful for a potential reimplementation of `newDataValueFromValueField` (see #45), compared to using the default implementation of an MD5 hash.

Pretty simple rule:
* Just make it an ISO time stamp
* with no plus
* and no leading zeros (both don't add information).
* Replace the `Z` with the actual time zone.
* Drop the calendar model. If there are two identical looking dates in Gregorian and Julian, both will be found. Better than none found. The field is not required to be unique, or is it?
* Drop before and after. Not useful in equality checks. If I'm searching for a date I can't necessarily know what strange before and after values were entered when the value was created. It may be `-10` with `PRECISION_10a` while I'm searching for `-10` in years. The most straight-forward way to solve this is to just ignore the precision. That's what the min and max fields are for.

By the way, there is currently no way to query the min and max fields.
It's 9 logical lines of code (not counting the initial type check). But you are right, there is some stuff going on here that could be split off (e.g. one method for the year and an other for the time zone). Will try.