Mark unconditionally-safe implicit coercions as leakproof

I went through the system's built-in implicit coercions to see
which ones are unconditionally successful. These could all be
marked leakproof, as per attached patch. This came up in the
context of the nearby discussion about CASE, but it seems like
an independent improvement. If you have a function f(int8)
that is leakproof, you don't want it to effectively become
non-leakproof when you apply it to an int4 or int2 column.

One that I didn't mark leakproof is rtrim1(), which is the
infrastructure for char(n) to text coercion. It looks like it
actually does qualify right now, but the code is long enough and
complex enough that I think such a marking would be a bit unsafe.

Any objections?

regards, tom lane