Added support for decoding plain PPM formats

[Piolie]

Resolves #860
Resolves #4999
Builds upon @gofr's PR draft #5009.

Changes proposed in this pull request:

• only adds decode support, not encode support;
• includes several tests;
• does error handling;
• is also affected by PGM and PPM maximum grey/color value is ignored #5008. It would be easy to fix this. However, it would make the results of the raw and plain formats inconsistent, so I decided to leave it as is;
• in plain PBM the inter-token whitespace is optional, so the decoder differs from the one for the other formats;
• there is also a hack to handle the fact that the 32-bit PGM extension expects signed ints, unlike the 8- and 16-bit ones, which are unsigned.

I made the changes on top of my other, still open, PR (#5121).

gofr's PR could potentially read the whole file at once (if there are no LFs) which for very large files could take up lots of memory. To avoid this, I tried to read one char at a time and although the implementation was easy, the performance was poor. I finally opted to read 1 MB blocks and process each one instead. The code ended up being more complex,* so there's that. On the bright side, it could easily be adapted not to _pull_fd, if it's any use.

*Strictly speaking, the PPM format doesn't allow comments in the raster section. However, these are commonly used. Ignoring them even when they span several blocks or split tokens in half was the hardest part.

[djbuijs]

I'm looking for this feature as well. What's holding up the merge? I'd be happy to help bring this over the finish-line if there's anything left to do.

[radarhere]

After #6242, it has become apparent that the hopper_32bit had a maximum value outside of the 0-65535 range. So I've removed those test images.

[radarhere]

@djbuijs I've now resolved the merge conflict, and added support for arbitrary maxval in plain formats to continue the work of #6119. Those were the issues that I was conscious of. What's left is just reviewing it to make sure that everything is correct and there's no straightforward improvements to be made.

[djbuijs]

Thank you @radarhere!