The PDF operator stream in this file does:

 W <path> n /Image Do

The filter code therefore currently tries to deal with the 'W'
without a path being defined. Currently it bounds it, finds it
is an empty rect, and therefore suppresses the image.

According to the PDF spec though, W and W* are not supposed to
look at the path at the point they are called. Instead they
merely set it up so that a side effect of the next 'path painting
operator' (in this case 'n') is to intersect the clip path
AFTER than operator has taken place.

This commit therefore changes the behaviour of the filter to
follow this. All we do when we get a 'W' or a 'W*' is to set a
new clip_op field. Whenever we then process a path painting
operator, we look at this field, and process W or W* as
appropriate.

We are at pains to forward the W or W* operator AFTER the path
has been processed, but before the path painting operator
is sent. This should keep bugged renderers such as Preview
happy.

The has meant that the culler handling has changed slightly
in that the culler now doesn't deal with CLIP paths separately
to FILL or STROKE paths, but rather now as a combination (e.g.
CLIP_FILL_PATH). Trying to deal differently with CLIP and FILL
paths (for example) would probably have gone wrong in the past
so there is no real downside here.