bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

[Max Nikulin]

Consider the following change of `encode-time' calling convention: last 
3 elements of the TIME argument as a list should be optional. I mean 
IGNORED, DST, and ZONE.

     (encode-time '(0 30 20 07 04 2022 nil -1 nil))
     (encode-time '(0 30 20 07 04 2022)) ; currently causes an error

Since Emacs-27 time fields as separated arguments are considered 
obsolete for calls of `encode-time'. Org mode keeps compatibility with 
Emacs-26 where passing all time components as a single list is not 
supported. Moreover, some time ago an attempt to use new style argument 
in the Emacs git repository (the change was never committed to the Org 
repository) caused a bug with handling of daylight saving time. See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54731
for more details, the commit reverted the changes is 8ef37913d3.

I have tried to create a compatibility wrapper for Org mode that chooses 
calling convention of `encode-time' in dependence of Emacs version. I 
have realized that there are enough call sites where components of time 
are gathered from scratch and not obtained from e.g. prior call of 
`decode-time'. It is inconvenient to add 3 extra mandatory components at 
the each place. I am reluctant to add a helper that accepts 6-components 
list and adds 3 fields to the end of the list. I am afraid that it may 
affect e.g. agenda performance.

From my point of view it is better to change implementation of 
`encode-time' so that it may accept 6-component list SECOND...YEAR. It 
should not add noticeable performance penalty but makes the function 
more convenient in use.

Old-style separate arguments for time components permits optional fields 
ended with ZONE. I do not mind that it should be deprecated since it is 
the source of surprise similar to the mentioned bug. Daylight saving 
time field matters only as a list component and ignored as a separate 
argument (by the way, it should be stressed in the docstring). It is too 
easy to confuse list and separate arguments in the code since both ways 
works but with a subtle difference: nil does not mean ignore the value.

     (encode-time '(0 30 20 07 04 2022 nil nil nil)) ; wrong!
     (encode-time 0 30 20 07 04 2022 nil nil nil) ; no problem

In the Org code it is unsure which way to call `encode-time' is more 
convenient. In a half of the cases a list is obtained from another 
function, but another half is timestamp built from computed components. 
Unless the inconsistency with DST I would say that both ways to call the 
function should be supported.

So my proposal is to not force Org mode to use new calling convention 
for `encode-time' till DST and ZONE list components will became optional 
ones in a released Emacs version. For a while minor changes in a couple 
of places in Org code should make it immune to accidental usage of new 
calling convention (modulo compatibility).