Introduce Pdfium version tracking feature flags

[ajrcarey]

Follow-on from #151, #152. Upstream Pdfium has started making more aggressive changes to their API without prior announcement (as far as I can tell) and without a formal deprecation strategy. In light of this, it seems prudent to offer some form of Pdfium version pinning in pdfium-render.

The simplest approach is to gate changed functionality behind feature flags, with the latest feature flag always tracking the latest version and set by default. This allows consumers to override the version to pin their PdfiumLibraryBindings to a specific Pdfium version.

This issue was raised following the release of Pdfium 6611 (as part of chromium/6611, packaged at https://github.com/bblanchon/pdfium-binaries/releases). Therefore the initial feature gates offered should be pre-6611 and 6611 itself, with latest being set to 6611 and additional gates being added as new backward-incompatible releases emerge in the future.

[ajrcarey]

Introduced following feature flags:

• pdfium_6569 - for everything earlier than release 6611
• pdfium_6611 - latest release (July 2024)
• pdfium_latest - default feature, currently set to pdfium_6611
• pdfium_future - for testing API changes that are published in Pdfium source but not yet built into a release

[ajrcarey]

Actually, it occurred to me that the release archive at https://github.com/bblanchon/pdfium-binaries/releases lets us add far more granular backward compatibility, since those releases also include the Pdfium header files. Selected a release per month for the last year, creating feature flags:

• pdfium_6611
• pdfium_6569
• pdfium_6555
• pdfium_6490
• pdfium_6406
• pdfium_6337
• pdfium_6295
• pdfium_6259
• pdfium_6164
• pdfium_6124
• pdfium_6110
• pdfium_6084
• pdfium_6043
• pdfium_6015
• pdfium_5961

This should be more than enough options.

Reworked build.rs to generate bindings for all sets of header files present in include/. Bound feature flags to bindings selection. Reworked adjusted font and text object functionality changed in latest release in #152 and #151 to use feature flags.

While reworking the bindings generation, had a think about the source code layout. The new bindings approach generates a lot of additional files, and so raises the question of how to organise them. I've been meaning for a while to reorganise the source code layout, so this seemed as good a time as any to take the plunge and do that at the same time.

[ajrcarey]

No changes required to tests or examples. Bumped crate version to 0.8.24. Updated README. Updated docgen-specific imports. Updated github actions workflow to test documentation generation as part of automated build. Ready to publish as release 0.8.24.