line endings in Lout

[Jeff Kingston]

In response to a suggestion from a user I have modified Lout so
that all the miscellaneous types of files it reads (font metrics
files, mapping files, @PrependGraphic files, database index .li
files, even files of error messages from @Filter processes) can
end in CR, LF, CR+LF, or LF+CR.

This should make life easier for peope moving files around
between operatings systems.

The only kind of file that doesn't have this flexibility in
my current development version is Lout source files, including
database (.ld) files.  I'm interested in modifying Lout so
that these files also have this flexibility.  There are two
issues:

* Lout currently employs a complex but allegedly very fast
  lexical analyser for Lout source files.  This would have
  to be updated very carefully.  Well, I can do that.

* Database index files have to be random-accessed using
  ftell().  This has been a problem area in the past, with
  ftell() giving wrong (anyway, inconsistent) answers in
  files opened for reading as text that have CR+LF or
  LF+CR newlines.  Uwe provided a heroic fix for this
  problem a few years ago.

Anyway, to the point.  What I think would be good would be
if Lout read in all source files and database files in
binary mode on DOS - thus it would see both characters
at the line end, but that would be OK because that's
what Unix would show anyway when reading a DOS file,
and we would be handling that.

The binary mode would ensure that ftell() always did
the right thing and Uwe's fix could be retired.

Files would continue to be written in text mode, so
that on unix you got single-character line ends and
on DOS two-character line ends.

Since I've never used a DOS system in my life, and have
no way to test stuff on DOS, I would be very grateful
if DOS-savvy people could comment on the feasibility
and desirability of this proposal.

Jeff Kingston