Remove pgindent ecpg exclusion pattern

Report by Tom Lane
With ecpg exclusion removed, re-run pgindent for 9.4

Report by Tom Lane
doc: Fix DocBook XML validity

The main problem is that DocBook SGML allows indexterm elements just
about everywhere, but DocBook XML is stricter.  For example, this common
pattern

    <varlistentry>
     <indexterm>...</indexterm>
     <term>...</term>
     ...
    </varlistentry>

needs to be changed to something like

    <varlistentry>
     <term>...<indexterm>...</indexterm></term>
     ...
    </varlistentry>

See also bb4eefe7bf518e42c73797ea37b033a5d8a8e70a.

There is currently nothing in the build system that enforces that things
stay valid, because that requires additional tools and will receive
separate consideration.
Improve comment for tricky aspect of index-only scans.

Index-only scans avoid taking a lock on the VM buffer, which would
cause a lot of contention. To be correct, that requires some intricate
assumptions that weren't completely documented in the previous
comment.

Reviewed by Robert Haas.
hash_any returns Datum, not uint32 (and definitely not "int").

The coding in JsonbHashScalarValue might have accidentally failed to fail
given current representational choices, but the key word there would be
"accidental".  Insert the appropriate datatype conversion macro.  And
use the right conversion macro for hash_numeric's result, too.

In passing make the code a bit cleaner and less repetitive by factoring
out the xor step from the switch.
Fix interval test, which was broken for floating-point timestamps.

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.

It was designed to test the longest possible interval output length,
so removing four zeros from the number of hours, as this patch does,
is not ideal. But the test still has some utility for its original
purpose, and there aren't a lot of other good options.

Noah Misch suggested a different approach where we test that the
output either matches what we expect from integer timestamps or what
we expect from floating-point timestamps. That seemed to obscure an
otherwise simple test, however.

Reviewed by Tom Lane and Noah Misch.
Fix some more confusion between uint32 and Datum.