Update our timezone code to IANA tzcode2026b

Here's a patch to do $SUBJECT. I looked into this due to Andres'
report of a Valgrind uninitialized-memory complaint [1]/messages/by-id/4uukubkg3t5eavtxxzfa7smqbnqqvl3ysl7aptmj77zbtdxjh3@krjnfntcirw6. I can
confirm that Valgrind no longer complains about this code.
However, it seems like the uninitialized-memory issue didn't
have any practical effect. The files generated by zic are
mostly the same as before, and for the couple dozen that are
not, testing with "zdump -v" shows that they represent the same
set of timestamp transitions as before. I suppose that those
changes are from internal algorithmic changes in zic. One file
that changed was Asia/Tbilisi, which is called out in the upstream
release notes for 2026a as no longer containing a useless no-op
transition. I didn't bother trying to trace down the other data
changes.

There are a lot of changes in this patch, since we hadn't done
a similar update since 2020. One that is rather annoying for
our purposes is that they changed the signatures of both
tzload() and tzparse(). Which they're entitled to do, both
of those being internal to localtime.c --- except we'd unwisely
exposed them as additional API. I think the best thing to do
is make them both local functions again, so that they can
track upstream, and instead export our own wrapper function.

A question that immediately raises is whether it's enough of
an API break to prevent back-patching this. Historically we've
usually back-patched tzcode updates to ensure that we'll still
be able to read future tzdata updates, and I was intending to
do so again with this. But perhaps this API break is a reason
not to. I don't see any really strong reason why extension
modules would be calling tzload() or tzparse(), but maybe
somebody is. So at the moment I'm leaning to "no backpatch".

I'll park this in the upcoming CF for now.

regards, tom lane

[1]: /messages/by-id/4uukubkg3t5eavtxxzfa7smqbnqqvl3ysl7aptmj77zbtdxjh3@krjnfntcirw6