Improve DOCX layout for floating images, drop caps, and footnotes

[peterwilli]

The current library lacks proper render capabilities for images and footnotes. Also added some missing features from the format.

To demonstrate, I used this sample docx: https://filesamples.com/samples/document/docx/sample1.docx

Here is page 5 before the PR:

Here is the same page, but after this PR:

Here is page 7 before this PR:

Here is page 7 after:

[peterwilli]

Fixed the headers now as well

[mantissaman]

Sorry for the long silence on this one. The before and after renders are convincing and I do want the feature.

The branch has drifted from main since March, and there are three things that need your hand before it can land.

1. The image crate. crates/rdocx-layout/Cargo.toml asks for image = { workspace = true }, but I removed image from the workspace dependencies in 9b01beb while clearing dependency CVEs. That was my call, so to be clear, I am happy to take it back for this feature. Please add it to [workspace.dependencies] in the root Cargo.toml as part of the rebase.

2. quick-xml went from 0.37 to 0.41 on main. crates/rdocx-oxml/src/drawing.rs around lines 340 and 377 uses BytesText::unwrap_or_default and .trim(), and neither of those exists in 0.41 any more.

3. cargo fmt --all --check fails on the branch. engine.rs around 822 and 968, and paginator.rs around 499.

There is also a conflict on Cargo.lock, but that one just needs regenerating.

One design note while you are in there. anchored_image_wrap_extents decodes the whole PNG to RGBA and walks every pixel with get_pixel to find the alpha bounds, and it does that on every call with no caching. On a large photo that is a big buffer and a lot of bounds checked reads, all inside layout. Caching by embed_id and iterating with enumerate_pixels would help. You can also stop early once the bounds already cover the full width.

No rush. Give me a shout when it is rebased and I will get to it quickly this time.