Render inline images (BI/ID/EI) and clean up FQN code-style issues

Implements the inline-image roadmap item: instead of pre-stripping inline
image blocks, the preprocessor now promotes each one into a synthetic Image
XObject and substitutes a `/__inline_image__N Do` invocation into the
content stream. The rest of the renderer treats it exactly like a regular
Image XObject and reuses the existing buildGrayImage / buildRgbImage /
buildCmykImage / ImageIO decode paths.

Two framing strategies are used so the parser doesn't get confused by
binary data:

- For DCT / DCTDecode / JPXDecode filters, find the JPEG end-of-image
  marker (FFD9) instead of scanning for "EI" bounded by whitespace, since
  JPEG payloads routinely contain byte sequences that look like EI by
  accident.
- For other filters (including no filter and FlateDecode), keep the
  whitespace-bounded EI heuristic but stop trimming "trailing whitespace"
  greedily -- image bytes can legitimately be 0x00 or 0x0A and the spec
  guarantees exactly one whitespace byte before EI.

Abbreviated dict keys (/W, /H, /BPC, /CS, /F) and full names (/Width,
/Height, ...) are both accepted; abbreviated colorspace values (/G, /RGB,
/CMYK) and full names map to component counts.

Tests:
- inlineImageRendersAtCtmLocation builds a 2x2 DeviceGray inline image
  with a [black, white; white, black] checker, scales it 120x via a cm,
  and asserts the rendered page contains dark pixels in the right region.
- jpegInlineImageDecodes uses PdfContentByte.addImage(image, ..., true)
  to embed a green JPEG as an inline image, then asserts the rendered
  page contains green pixels.

README's status section now says inline images render, and the
limitations list no longer mentions them.

Also addresses Codacy's "unnecessary fully qualified name" warning on
java.util.List / java.util.Set usage. The class now imports List, Set,
Arrays, ByteArrayOutputStream, StandardCharsets and Rectangle2D directly
instead of inlining the FQNs; 7 call sites simplified.

Module test suite: 86 tests, 0 failures.

Author: claude

openpdf-renderer/README.md

@@ -130,12 +130,15 @@ renderer falls back to a generic Java2D family picked by PostScript-name
 heuristics — glyph widths from the PDF font are still respected,
 but shapes are only approximate.
 
-Inline images (`BI`/`ID`/`EI`) are stripped from the content stream before
-parsing — they aren't rendered, but they don't derail the rest of the
-page either. Shading (`sh`), pattern / shading colors and type 3 font glyph
-operators are silently ignored. Pages that rely heavily on those features
-may render with missing content. Adding more operators is a localized change
-in `OpenPdfCorePageRenderer`.
+Inline images (`BI`/`ID`/`EI`) are now rendered: a preprocess pass promotes
+each inline image into a synthetic Image XObject (with JPEG framing detected
+by the JPEG `FFD9` end-of-image marker when the filter is `DCTDecode` to
+sidestep the ambiguous whitespace-bounded `EI` heuristic), then the rest of
+the renderer treats it like any other XObject. Uncompressed, Flate-decoded
+and JPEG inline images are supported. Shading (`sh`), pattern / shading
+colors and type 3 font glyph operators are silently ignored. Pages that
+rely heavily on those features may render with missing content. Adding more
+operators is a localized change in `OpenPdfCorePageRenderer`.
 
 For pages that need features outside this supported subset and you want
 pixel-perfect output today, the deprecated `PDFFile` / `PDFPage.getImage(...)`
@@ -158,9 +161,6 @@ The legacy in-tree parser still wins on real-world PDFs that exercise:
   no ICC profile, no UCR/BG. Anything color-managed will look noticeably
   wrong. Real fix: respect the ICCBased profile via `java.awt.color.ICC_Profile`.
 - **Pattern and shading paint** (`pattern`, `sh`). Ignored.
-- **Inline images.** Currently dropped; the parser-level strip keeps the
-  rest of the page rendering. Re-implementing them on the existing raster
-  helpers is straightforward.
 - **Soft masks (`SMask`) and transparency groups.** Ignored; image alpha
   honors `ca` only, not per-pixel masks.
 - **Indexed / Separation / DeviceN color spaces** for images and paths.