ENH: add width, height, and data_size properties to ImageFile

[itisar-345]

Previously, inspecting an image's dimensions or size required fully decoding it via .image or .data, even if the caller only wanted to
filter out images that are too large to process.

ImageFile now exposes:

• .width : image width in pixels, read from the stream's /Width
• .height : image height in pixels, read from the stream's /Height
• .data_size : compressed byte size of the stream, read from the raw stream bytes (no decompression)

All three are read directly from the PDF stream header/raw bytes and require no image decoding, so they remain cheap even for large or numerous images.

.data and .image continue to be populated eagerly as before; this change is purely additive and does not alter existing behavior.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.87%. Comparing base (11a0f77) to head (f80b843).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3881   +/-   ##
=======================================
  Coverage   97.87%   97.87%           
=======================================
  Files          57       57           
  Lines       10760    10781   +21     
  Branches     2014     2018    +4     
=======================================
+ Hits        10531    10552   +21     
  Misses        127      127           
  Partials      102      102           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[stefan6419846]

Thanks for the PR. I have added some remarks to the proposed changes.

[stefan6419846]

See inline comments.

Additionally, unlike the PR description seems to propose, this currently does not have any benefits regarding speed, as the actual image decoding still happens on load time?

[itisar-345]

See inline comments.

Additionally, unlike the PR description seems to propose, this currently does not have any benefits regarding speed, as the actual image decoding still happens on load time?

To be precise about what this PR actually does: data and image are still populated eagerly in _get_image() and the inline-image path, so decoding still happens at load time exactly as before. This PR doesn't change that. What it adds is just three cheap read-only accessors (width, height, data_size) that read directly from the stream header/raw bytes, for callers who only need those values and don't want to touch .data/.image in their own code.

So the actual benefit is at the call site, not in pypdf's internal decode path: e.g. page.images[0].width avoids a caller having to open the image data themselves just to check dimensions. I'll update the PR description and remove the "cheap"/no-decode-implying language from the docstrings so it doesn't overstate what's going on.

If actually deferring the eager decode of data/image (true lazy loading) is something you'd want, I think that's a separate, bigger change — happy to open a follow-up issue for it if useful, but I'd rather keep this PR scoped to the additive properties.

I've also pushed fixes for the other inline comments (dropped the redundant int() casts on width/height, applied your NullObject()/is_null_or_none suggestion for the /Length fallback, shortened the _stream_obj docstring, and added tests covering the fallback path and the no-stream error case). Let me know if anything still looks off once you re-check.