Return the same type from timeencode if the units are not changing

[felixcremer]

When I am doing a timedecode and then a timeencode with the same underlying units I would have expected that we get the same type back. This is fixed here by comparing the old and the new units. And if so not dealing with the plength but returning the difference immediately.

While implementing this, I was wondering why the main work of the timeencode function is in a dispatch for an AbstractArray and then we wrap the single instance in an array. We could also do the main work in the method for a single element and make the one for the abstractArray be a broadcasted version of this method.

This would make it easier to specify the timeencode behaviour of specific types.
For example we could get rid of the if ismissing case by dispatching on missing and having a
timeencode(::Missing) = missing method.

[Alexander-Barth]

While implementing this, I was wondering why the main work of the timeencode function is in a dispatch for an AbstractArray and then we wrap the single instance in an array. We could also do the main work in the method for a single element and make the one for the abstractArray be a broadcasted version of this method.

Actually, the problem is that types depend on the values (units, calendar). For a large arrays, this can be quite slow.

There is a lot of this code, that can be done differently since the time origin and the news are now flexible.
I did this in the branch improve_timeencode. Your test case also passes. Do you have the time to test it for your case?