This incomplete PNG decoder presents as an Iterator reading u8 bytes directly from a Reader.

Aproaching a png decoder as an Iterator requires significantly less Heap than
the traditional batch aproach.

On Precursor, this enables PNG bytes to be intercepted at the network interface
and processed into the much smaller gam::Bitmap format without ever having to
store the original PNG file.

caused by flakey Internet connection

The checksum calc is inner-loop so removed for performance gain.

If a hacker can manipulate a byte then then they can manipulate a RGB
byte or a checksum byte - so the checksum doesn't really give any
protection from hacking afaik. I presume the checksum is in there to
detect corruption during storage or transmission - but if a couple of
bytes are corrupted you will not notice the change in the image - and
if a lot of bytes are corrupted then the distortion in the image will be
obvious. This is even more the case in Precursor, where we are shrinking
and dithering the image as a matter of course. So I don't really see the
point of the checkum

png filter specification calls for initial prior_line = [0u8]
see: https://www.w3.org/TR/PNG/#9Filters
but [0u8] results in distortion ???????
so use [125u8]