Separate ftell from fseek logic and avoid modifying FILE data (#16532)

ftell semantics are distinct from fseek(SEEK_CUR) especially when it
is called on a file handler that is not yet active.  Due to this
caveat, much care needs to be taken while modifying the handler data
and hence, this first iteration on separating out ftell focusses on
maintaining handler data integrity at all times while it figures out
the current stream offset.  The result is that it makes a syscall for
every offset request.

There is scope for optimizing this by caching offsets when we know
that the handler is active.  A simple way to find out is when the
buffers have data.  It is not so simple to find this out when the
buffer is empty without adding some kind of flag.
Use cached offset in ftell when reliable

The cached offset is reliable to use in ftell when the stream handle
is active.  We can consider a stream as being active when there is
unflushed data.  However, even in this case, we can use the cached
offset only when the stream is not being written to in a+ mode,
because this case may have unflushed data and a stale offset; the
previous read could have sent it off somewhere other than the end of
the file.

There were a couple of adjustments necessary to get this to work.
Firstly, fdopen now ceases to use _IO_attach_fd because it sets the
offset cache to the current file position.  This is not correct
because there could be changes to the file descriptor before the
stream handle is activated, which would not get reflected.

A similar offset caching action is done in _IO_fwide, claiming that
wide streams have 'problems' with the file offsets.  There don't seem
to be any obvious problems with not having the offset cache available,
other than that it will have to be queried in a subsequent
read/write/seek.  I have removed this as well.

The testsuite passes successfully with these changes on x86_64.
Fix up formatting
Fix up formatting in tst-ftell-active-handler.c
Fix libm-test.inc:print_complex_max_error handling of some error cases.

When regenerating ulps incrementally with "make regen-ulps", the
resulting diffs should only increase existing ulps, never decrease
them.  This allows successive uses of "make regen-ulps" on different
hardware or with different compiler configurations to accumulate ulps
that are sufficient for tests to pass in a variety of configurations.

However, sometimes changes that decrease ulps are wrongly generated;
thus, when applying
<https://sourceware.org/ml/libc-alpha/2014-02/msg00605.html> I had to
remove such changes manually.  The problem is
print_complex_max_error.  If the ulps for either the real or the
imaginary part of a function are out of range, this function prints
the maximum ulps seen for both parts, which then replace those
previously in libm-test-ulps.  So if the ulps for one part are bigger
than recorded before, but those for the other part are smaller, the
diffs reduce existing ulps.

This patch fixes the logic so that only increased ulps get printed.

Tested x86_64 ("make math/tests", and "make regen-ulps" in a situation
with ulps manually modified so one part would go up and the other
down, to confirm the changes have the intended effect then).

	* math/libm-test.inc (print_complex_max_error): Check separately
	whether real and imaginary errors are within allowed range and
	pass 0 to print_complex_function_ulps instead of value within
	allowed range.
hppa: Regenerate ULPs.
hppa: Regenerate ULPs again.