Use per-aggregate memory contexts for invertible aggregates.

Otherwise, we potentially leak memory whenever the aggregation
of such an aggregate is restarted, because unless they're all
restarted simulatneously, we never get to reset the aggcontext.

Doing this required moving AggCheckCallContext into nodeWindowAgg.c,
because it now needs to peek into WindowStatePerAggData. That function
now also asserts that it's not being called from a true window function -
doing that was always wrong, because the aggregation context it returns
is't suitable for use by a true window function.
Mark function as not using the inverse transfer function if the
frame start clause is UNBOUNDED PRECEEDING.
Fixed comment layout
Added a list of partially and non-invertible aggregates to the window function docs.
Small tweak to create_aggregate.sgml
Cleaned up xaggr.sgml.

I've tried to shorten things a bit - it certainly seems sensible
to discuss the case of inverse transition functions and floating-point
type, but that page is about aggregates, not floating-point
arithmetic.

I also didn't like that the previous text recommended creating your
own float aggregate "if you can live with the roundig anomalies".
That suggests that the paragraph about explains all the problems
that can arise, but it doesn't, and it shouldn't. People who
understand enough about floating-point arithmetic to make an
informed decision won't need such a suggestion, and we shouldn't
encourage those who don't to play it fast and loose.

This concludes my work on the documentation, or at least so I hope.