Tracking issue for semver-breaking v0.18

[Shnatsel]

We'll want to get these changes done for the semver-breaking v0.18 release:

• High-level compression options API #503
• Bump bitflags to v2 #400 (already has a duplicate now: Upgrade bitflags to 2.0. #516 )

Open questions:

• Do we want to disable broken streaming APNG encoding? Broken APNG is produced with StreamWriter #411
• Do we want to merge Remove Reader::scrach_buffer field + resulting breaking API changes. #421? It seems the consensus is to go with Add Reader.read_row for decoding into caller-provided buffer. #493 instead, but we need to commit to one of these options.
• Are Re-encode example #418 and Write new image using chunks from StreamingDecoder? #253 still relevant? If so, this seems like a good time to fix them.
• Do we care to fix OutputInfo::line_size should be a method #521 ?
• Encoding parameters inconsistently duplicated between Encoder and Info #522

[fintelia]

Another possible item would be adding BufRead and/or Seek bounds for the decoder. The image crate already requires them, so no further breakage would be required there.

• Discussion of BufRead: Discussion: PNG decoding performance improvement opportunities #416 (comment)
• One usecase for Seek: Need public API to seek to another APNG frame #510, though it could also be helpful for removing the need for PngDecoder::with_limits in the image crate.

[anforowicz]

Do we want to merge #421? It seems the consensus is to go with #493 instead, but we need to commit to one of these options.

I am fine with either approach.

I think that #421 results in a slightly cleaner API (no read_... vs next_... discrepancy; can remove Row and InterlacedRow structs). OTOH, #493 may still be better overall:

• Some clients may not care about copying - in these cases its nice if png crate helps with buffer management. (e.g. it was easier to start SkPngRustCodec because of this)
• Avoiding breaking changes is valuable even if it results on a slightly more verbose/clunkier API (and it's not that bad anyway)

I think that we agree that these changes will be beneficial for performance. OTOH, maybe we can/want to wait to measure the actual impact in Chromium usage (especially since avoiding the extra copy also requires some Chromium-side work). I am totally fine with waiting (the new benchmark results would hopefully come before the end of 2024; nothing is blocked on my side without these PRs - I can always patch them in as long as there is a consensus that one of them will get merged eventually).