Build: spec: avoid dirty "timezone hack" with more sane "git archive"

The described scenario could allegedly only happen when a committer
(~CommitDate, possibly subject of some 3rd party "helper") failed to
set up time sanely for that machine wrt. time and/or timezones (offset
to UTC), to start with.

But let's go the extra mile so as to ensure that locally generated
source archives in question (via "[g]make {export,srpm}") carry files
with the modification time corresponding to the birth of such archive,
see [1]:

'git archive' behaves differently when given a tree ID versus when
given a commit ID or tag ID.  In the first case the current time is
used as the modification time of each file in the archive.  In the
latter case the commit time as recorded in the referenced commit
object is used instead.

This way, things can only go wrong if either the machine where the
archive/SRPM gets generated or the other one, where such package gets
build, lacks sane time adjustment (hence they will certainly mismatch,
not the case if both phases take place with the same machine).

[1] https://github.com/git/git/blob/v2.17.0/Documentation/git-archive.txt#L24-L28