Customize fringe widths

[Kim F. Storm]

As a preparation for adding customization of the fringe bitmaps,
I'm working on making the fringe widths configurable.

So far, I have changed the X version to adjust the fringe widths of a
frame via a new x-set-fringes function, and it seems to work ok.

I'm planning on adding these as frame-parameters as well.

Here is the preliminary documentation string for x-set-fringes:

  x-set-fringes is a built-in function.
  (x-set-fringes FRAME &optional LEFT-WIDTH RIGHT-WIDTH)
  
  Set the width of fringes for FRAME.
  FRAME nil means use the selected frame.
  The optional LEFT-WIDTH argument specifies the width of the left fringe.
  The optional RIGHT-WIDTH argument specifies the width of the right fringe.
  The actual size of the fringes is adjusted so that together, they occupy an
  integral number of columns.  Normally, the extra width is distributed
  evenly on the left and right fringes; however, if either of the width
  arguments is negative, the corresponding positive number is used as a
  fixed width for that fringe.

However, there are some quirks which are rather fundamental, so I would
like to raise these as issues before I finalize the changes:

1) If the fringe width is less than the width of the bitmap, should
the bitmap be clipped, or should the fringe width be adjusted to be
able to hold the widest bitmap?

2) If I set the width of a fringe to zero, the corresponding
truncation/continuation glyphs are not shown.

It might be sensible to fall back to using the 20.x truncation glyphs,
but this doesn't seem to be so simple, as the code for X seems to
implicitly assume the existence of the fringes.

However, it could also be argued that if the fringes are explicitly
removed, then the truncation/continuation information simply isn't
visible.

3) It actually looks more sensible to adjust the fringe widths (and
perhaps the bitmaps) on a per-buffer basis, rather than per-frame.

But there are many other things which should be per-buffer rather than
per-frame, so this should probably wait until we know how to fix this
in general.

4) As is the case for most of the code for X in xterm and xfns, there
is almost identical code for w32 and mac.

If I change this for X, is it assumed that I will also make the same
changes for w32 and mac (which I cannot test), or can I depend on the
maintainers of the w32 and mac ports to 'pick up the pieces' ?

5) If the left fringe is removed, it is easy to show the 'empty line
indicator' in the right fringe.  I already tried this, and it looks ok.