Parallel safety tagging of extension functions

Hi,

I have gone through all our extensions and tried to tag all functions
correctly according to their parallel safety.

I also did the same for the aggregate functions in a second patch, and
for min(citext)/max(citext) set a COMBINEFUNC.

The changes for the functions is attached as one huge patch. Feel free
to suggest a way to split it up or change it in any way if that would
make it easier to review/apply.

Some open questions:

- How should we modify the aggregate functions when upgrading
extensions? ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My
current patch updates the system catalogs directly, which should be safe
in this case, but is this an acceptable solution?

- Do you think we should add PARALLEL UNSAFE to the functions which we
know are unsafe to make it obvious that it is intentional?

- I have not added the parallel tags to the functions used by our
procedural languages. Should we do so?

- I have marked uuid-ossp, chkpass_in() and pgcrypto functions which
generate random data as safe, despite that they depend on state in the
backend. My reasoning is that, especially for the pgcrypto functions,
that nobody should not rely on the PRNG state. For uuid-ossp I am on the
fence.

- I have touched a lot of legacy libraries, like tsearch2 and the spi/*
stuff. Is that a good idea?

- I decided to ignore that isn_weak() exists (and would make all input
functions PARALLEL RESTRICTED) since it is only there is ISN_WEAK_MODE
is defined. Is that ok?

Andreas