extmod/modframebuf: Add attributes for width, height, format and stride. - #17328

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:  +304 +0.036% standard[incl +64(data)]
      stm32:  +112 +0.029% PYBV10
     mimxrt:  +104 +0.028% TEENSY40
        rp2:  +112 +0.012% RPI_PICO_W
       samd:  +108 +0.040% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:  +123 +0.027% VIRT_RV32

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.46%. Comparing base (2dc2e30) to head (63acb87).
⚠️ Report is 2 commits behind head on master.

@@           Coverage Diff           @@
##           master   #17328   +/-   ##
=======================================
  Coverage   98.46%   98.46%           
=======================================
  Files         176      176           
  Lines       22784    22796   +12     
=======================================
+ Hits        22435    22447   +12     
  Misses        349      349           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Some display drivers enable rotation where width and height may be transposed.

My subclasses maintain .width and .height attributes which match the attributes of the displayed image. These are derived from args passed to the constructor (height, width, some means of specifying orientation).

To expand on this, where rotation is done in code there may be no problem if the framebuf is instantiated with height and width attributes matching the image. But some hardware (e.g. ST7789) performs rotation in hardware, so the framebuffer's dimensions may not match those of the image.

Arguably no action is required here with such subclasses overriding the base class attributes, but comments are welcome.

Some display drivers enable rotation where width and height may be transposed.

Rotation feels like a problem best solved at a layer above FrameBuffer.

Or at least right now FrameBuffer has no concept of rotation, maybe in the future it could but I'm not sure exactly how that would work. For now the width, height and stride attributes are those used in clipping calculations, so seem sensible to expose.