Add a second renderer for scaling to non-integer sizes

[parasyte]

Related issues:

• Black border on resizing #106
• TBD whether this should address Feature request: force a particular scaling factor #89

The current state of this PR adds an example which implements a custom renderer for doing two-pass scaling to maintain high quality with the sharpest pixels possible on arbitrary image sizes. I would like to evolve this a bit to pull this custom renderer into the library and make it customizable.

There are a few gotchas to consider:

1. Pixels maintains an inverse scaling matrix for translating pointer coordinates to pixel buffer coordinates and back. Using a two-pass renderer needs to be aware of this.
   • Let A be the scaling matrix for the first pass and B be the scaling matrix for the second pass.
   • Right now, the inverse scaling matrix is always A-1
   • With two passes, it will need to be changed to (AB)-1
2. The naive approach that I originally wanted to take for implementing this second pass is to just make the user do it with Pixels::render_with() and our PixelsContext would allow referencing both renderers. I now see this is error prone. Not only because the inverse matrix will complicate this, but also because it would be possible to accidentally swap the two passes and end up with a bad result.
3. The ScalingRenderer is recreated every time the pixel buffer is resized. This has been fine up to now, but it complicates things with multiple passes. I think it makes more sense to make the renderer mutable and design a trait that can generically update the renderer when properties like the pixel buffer size changes.

For these reasons, I think a better API would be allowing some configuration at the PixelsBuilder level to choose whether you want one-pass or two-pass scaling, plus any scaling options. And those options can all follow through to correctly initialize and update the inverse scaling matrix and renderer.

It would be nice if PixelsContext could own a trait object for the renderer. Instead of owning two separate renderers, it would just own one (and the two-pass renderer would own the first pass). This would make swapping renderers easy in the future and could also allow changing the renderer at runtime (if that's a thing we want to do).

---

This might be YAGNI, but given that we have at least the one issue regarding the border and the fact that it is not at all obvious why the border exists, I think dealing with this head-on is appropriate.

[parasyte]

I was thinking about this the other day, but I'll log it here for documentation: I think this could be a suitable replacement for the outstanding issue in #151. In short, that issue is enabling horizontal texture filtering (smoothing) without introducing a second render pass. Since we need a second render pass anyway for this feature, I think it is worth taking advantage of that in #151 accordingly.

I'll have to revisit that PR after I sort out the outstanding issues in this one. :)