Properly support multiple DMD resolutions - #239

This PR was originally triggered by #233 for adding support to PIN2DMD-XL displays running at 192x64. A few major refactorings took place in order to achieve this.

Firstly, PIN2DMD-XL has a somewhat special API: It takes in RGB24 and 4-bit frames at 128x32, and the firmware centers the image over the 192x64 real estate. In fact, there isn't an API (yet?) to send RGB24 at 192x64. Then there's of course a 192x64 mode that takes in 4-bit frames.

So there are basically two major things that this PR adds:

1. Destinations are not either "resizeable" or "fixed" anymore, they can now have "multiple fixed" resolutions too (welcome IMultiSizeDestination!).
2. We now get to know the dimensions of each frame when rendering, and don't need to determine it from a previous SetDimensions() or the destination's fixed size

This had a few implications:

• Instead of sending byte arrays, we're now sending DmdFrames everywhere, which also contain the Dimensions.

• We never pass width and height anywhere anymore, because we now have Dimensions.

• Frames get cloned when entering the render graph. That means they can be manipulated without side effects to other destinations treating the same frame (the frame buffer doesn't get cloned, so it must be replaced, not manipulated).

• Since we now have frame objects, they are intelligent, i.e. they contain conversion and transformation logic previously awkwardly sitting in the render graph.

• The frame objects are:

  • DmdFrame for byte array frames (gray2, gray4, rgb24)
  • ColoredFrame for gray2 and gray4 including a palette
  • BmpFrame for bitmap frames
  • AlphaNumericFrame for non-DMD frames

  These are now created at the source, and are persisted (or converted into another type) until they reach the destination.

So how this this work?

When a destination offers multiple resolutions, the render graph figures out itself which resolution to send to the frame (see BaseFrame.GetTargetDimensions()). It boils down to:

• If a resolution matches the one of the frame, use that one.
• Otherwise, take the next-higher resolution than the frame
• If there is none, take the highest (and the frame will then be sized down later)

So the PinDmd2XL destination already gets the right resolution (the gray interfaces anyway, RGB24 must be resized since not supported at full res). All it has to do now is look at it and render it accordingly.

This PR closes #233.