This spins out of Bug 702196, though it's not strictly speaking
related. Bug 702196 deals with lines being incorrectly recognised
as being "thin". Thin lines aren't mitred. When we fix the
erroneous classification of lines as thin, this causes more
lines to be mitre joined than before. This in turn exposes
the bug that we (partially) fix here.

 gs -sDEVICE=pdfwrite -o out.pdf tests_private/ps/ps3cet/11-28.PS

 gs -sDEVICE=png16m -o out%d.png -r300 -dMaxBitmap=2G out.pdf

Page 4 of the output shows strange mitre extrusions from the edge
of paths.

Investigation shows the file is 'strokepath'ing the path (with
mitre joins), and the stroking the resultant path (again with
mitre joins). The initial 'strokepath' conversion includes little
"wedges" of path internally to give the "underjoin" in the path.
When restroked, due to the mitre join still being set, these
wedges turn into spikes.

The fix, implemented here, is to revise the way we do mitre joins.
For paths stroked using the "fast" code, with miter joins, we
perform slightly more complicated calculations at each join. This
allows us to do the joins by moving the existing points of the
paths 'inline'. This removes the need for the 'wedges', and
actually gives us a much cleaner path overall.

This *should* help with pathological scan conversion cases too,
because it means we will have fewer 'sleepers' in the 'train
tracks' when strokepath is used.

This may not kick in in all cases where we'd like it to, because
for some files, we use 'traditional' stroking, and so don't
execute this code. One way around this would be to change
gs_strokepath to disable 'traditional' filling in the presence
of mitre joins, but that produces strange effects, so we're
leaving it for now.