RFR: 8330532: Improve line-oriented text parsing in HotSpot [v7]

[John Rose]

>
> Drive-by comment: do we really need to combine input and output capabilities in one class, fileStream? Why not a dedicated fileOutputStream? APIs like setPosition() do not make much sense on an output stream.

No we don’t need bidirectional capability on one class.
That’s just the way fileStream was coded in the beginning
of HotSpot. This PR does not propose to redesign fileStream.
That class really ancient, and probably has lots more
technical debt we could fix.  There’s plenty of debt
go around, for many PRs.

Touching any part of this stream stuff certainly does
provoke plenty of larger questions of technical debt,
and how to reduce it moving forward.

I suppose we could remove the old function rewind
(not used anywhere?) and also the proposed functions
set/get_position and remaining.  The point is whether
we want capable file streams or not.  I think we
do, but of course the question is always which
capabilities.  And I don’t want to try to settle
that question in this PR; I just want to make
incremental progress.

Ioi, I would support reducing coupling with fileStream
by removing old rewind and new position/remaining
functions.  But I’d rather keep the new functions,
because I think they are likely to be useful.
I have future uses in mind, which might or might
not happen.  For example, open a CDS archive or
large config file, position the fileStream at the
base address of some textual configuration data,
and start reading.

Whether we do that or not, the idea of positioning seems
natural enough to HotSpot to put in now, or else later
in a similar form.