Support alternate formatting of unix timestamps

[jamadden]

Two of the standard external fields, CreatedTime and Last Modified, are currently defined to be Unix-style timestamps (floating point numbers representing fractional seconds since the epoch).

These are automatically added to all objects that aren't using the minimal dict external form:

https://github.com/NextThought/nti.externalization/blob/0200d1e7295869d843c03d2859ba19f8da05ea78/src/nti/externalization/externalization/dictionary.py#L58-L59

CreatedTime comes from the the createdTime attribute of an object (natively stored as a number) or the created attribute of a IDCTimes adapter of the object, stored as a DateTime object.

Last Modified comes from the lastModified or LastModified attribute of the object, or the modified attribute of the IDCTimes adapter on the object.

Defining different representations for those fields is difficult. The existing base classes automatically skip them, so defining them in interfaces doesn't make any difference:

https://github.com/NextThought/nti.externalization/blob/0200d1e7295869d843c03d2859ba19f8da05ea78/src/nti/externalization/datastructures.py#L232-L235

Over in nti.webhooks, we have a need to externalize those values not as unix timestamp numbers, but as ISO8601 formatted strings. Registering new externalizers for all classes isn't ideal (or necessarily feasible). Doing a replacement pass with a decorator could work, but (a) that's an expense I'd prefer to avoid and (b) decorators aren't named, so it's hard to limit the scope in which they apply (decorators are treated as component subscribers, which can't have names).

https://github.com/NextThought/nti.externalization/blob/0200d1e7295869d843c03d2859ba19f8da05ea78/src/nti/externalization/externalization/dictionary.py#L63-L69

nti.webhooks could specifically add its own named adapter pass after nti.externalization is done, but again, I'd prefer to avoid extra looping if we could do this directly "inline". The external forms can be deep and wide and require a lot of recursion; the C acceleration we already do for that case should be used.

I'd also like to avoid adding more expense to the standard hot paths to the extent possible.

I was thinking of something like adding a new field to nti.schema — UnixTimestamp — and using it in the appropriate interfaces, and then somehow handling that specially. I think the schema field makes sense regardless, but I'm not sure what the special handling would look like or where it would live.

It might be easiest/fastest to do it at the level at which we call get_created_time: do a named adapter lookup and use the existing function as a fallback. Except there's some complex handling to do the attribute-or-IDCTimes work, so we'd still want to be able to use those functions in the named adapters, probably.