Poor use of caching in rangetypes code

While digging around for the cause of the buildfarm failures in the new
rangetypes code, I noticed that range_gettypinfo thinks it can memcpy
the result of fmgr_info(). This is not cool. It's true that fn_extra
is likely to be NULL at the instant the copy occurs, but what will
happen if the called function is using fn_extra is that on *each call*
it will have to re-create whatever data it's caching there. That's not
only bad for performance but it means a per-call memory leak.

It looks like the reason that it's done this way is that some functions
call range_gettypinfo twice, presumably for types that could be
different ... but if they actually were different, then again the
caching would be counterproductive.

I think we need to fix this so that a cached RangeTypeInfo is used
in-place. The places that need two of them will need some extra code
to set up a two-RangeTypeInfo cache area.

Unless you see a hole in this analysis, I will go make the changes.

regards, tom lane