Add support for XEP-0202: Entity Time

@csh We'll see what Guus thinks.

I'd rather not discuss patches in the bug tracker, but since there is no associated forum post: The fact that legacy date format is obsolete doesn't mean that we shouldn't support it. There are IIRC still a few XEPs out there that require it.

Furthermore, I don't see how XMPPDateTimeFormat duplicates DatatypeConverter. If that would be true, you wouldn't needed to write the getUtcDate() utility method. What duplicates DatatypeConverter is util.FastDateFormat, and I may be worth to evaluate which ones performs better and should be used. Nevertheless, the requirement for a XMPP date/time formatter/parser utility class remains.

getUtcDate() is only needed, because DatatypeConverter requires a java.util.Calendar, rather than a date (because a Date alone holds no TimeZone information). It only puts the date into a Calendar and sets the TimeZone to UTC.

XMPPDateTimeFormat is in this case even less flexible because its format() method always formats as UTC.

@XEP-0090: I only know of XEP-0013 which refers to it. I asked the XSF about it and Peter Saint-Andre told me XEP-0013 will either be deprecated or updated to use XEP-0082.

I doubt that we need the flexibility to specify different timezones, as this data is likely only parsed by machines and not by humans.

If anybody's interested, I did a little test (DatatypeConvert vs XMPPDateTimeFormat), with the result, that DatatypeConverter is about 25% faster than XMPPDateTimeFormat, even if the Calandar object is newly created every time.

If you reuse the Calendar, its around double as fast.