preliminary patches for column number

[craig@jcb-sc.com]

>* Is "linecol" a good name for the struct?
>* Is "linecolno" a good replacement for "lineno"?
>* Likewise for DECL_SOURCE_LINECOL, EXPR_WFL_LINECOL, rtlinecol,
>NOTE_LINE_LINECOL, etc.

Another possibility is a break with old lingo.  Maybe use terminology like
`cursor' or `point' instead.

There's not just one line, or column, number, so "linecolno" seems
likely to be hard to remember.  "cur_point", for example, can be
remembered as "current processing point in the source file".  "src_point"
might be better.

"point", or whatever, should probably be a typedef, not just a struct,
since it doesn't necessarily always have to *be* a struct.  I've been
thinking about improving g77's relatively kludgey handling of this
same issue (it tracks line/col pairs separately!), and, rather than
assume a fixed boundary between the bitfields (as a C struct must),
I've thought it better to just go with an `int', `long int', or `long
long int', start with a typical boundary (for Fortran, 7 bits of
column# is almost always sufficient), then increase the bit-width of the
column number as needed, tracking the line#s at which these increases
happen (for reference by code that prints these "point" types).

Even if you don't want to do that now, it doesn't seem like it'd
hurt to accommodate it now by defining a typedef instead of a struct.

Note that g77 also freely overwrites `lineno' by pushing/popping it.
E.g., during its second pass over the list of Fortran statement, when
it actually does code generation, it sets `lineno' to the `point' for
the statement being compiled, rather than leaving it at, or near,
the `END' statement.  So g77 will probably have to be modified to
cope with whatever you do, though it shouldn't be *too* painful, and
I'm all for the thrust of what you're trying to accomplish!

        tq vm, (burley)