Harden for multi-scan JPEG

[nolmoonen]

Fixes #176, #177, and an additional problem found for multi-scan JPEGs with multiple, different restart intervals. I've added tests for the error cases using CC0 images, and added a description for the JPEG properties. In order to holistically fix #177, I've also added support for multi-scan JPEG that are truncated within the scan, and added a test for this as well (verify_encode_truncated_scan).

• The first commit addresses Incompatibilty with non-interleaved JPEG #176. The root cause is that before this PR, in some places "baseline" is understood to be a sequential JPEG, whereas the original codebase takes it to mean a sequential JPEG with a single scan. This causes the Lepton file header to be set incorrectly. I've also made a small refactor to merge read_first_scan and read_progressive_scan and have one function read_scan that reads any type of scan. The code was wrong here since it assumed that there can be no two initial DC scans in a JPEG.
• The second commit makes it easier to collect information about the image properties.
• The third commit addresses Incompatibility with non-EOI #177, where the problem is that it is not sufficient to stop parsing when the scan is read, it must be confirmed that the EOI marker exists. If it does not exist, the garbage must contain the two final scan bytes (since otherwise empty garbage implies that EOI exists). A refactor in read_jpeg_file allows the handling of garbage data to be the same for single- and multi-scan JPEGs.
• The fourth and final commit fixes behavior for JPEGs that contain more than one, different, restart intervals. I am not one hundred percent sure of the logic of the fix, but it is a result of a careful inspection of the original Dropbox implementation.

I realize that the PR is quite big, so please let me know if I can make any additional clarifications.

[nolmoonen]

@microsoft-github-policy-service agree