Register an optional transform provider for epubs

[pawanjay176]

Related to #15649

Adds a DocumentRegistry hook that lets a plugin provide an entry transform when opening epub files with crengine.

The transform object is passed to CreDocument, which uses the new loadEpubWithEntryTransform base bridge when present. Otherwise the existing loadDocument() path is unchanged. This change is purely additive and doesn't affect any existing koreader paths.

Relevant PRs in submodules:

• Expose importing a document from a passed LvContainerRef crengine#708
• Add a LVContainerTransform for interaction between koreader and crengine koreader-base#2477

---

This change is 

[pawanjay176]

Tested a simple lcp plugin with this code as a proof of concept in https://github.com/duralumind/lcp-rs/blob/minimal-koreader-plugin/lcpreader-minimal.koplugin/main.lua

[pawanjay176]

sample opening of a basic profile lcp encrypted book with the above plugin in the emulator. Reiterating that koreader has absolutely no lcp logic, its fully contained in the plugin. Sorry for the poor gif quality 😅

[poire-z]

Any way for you to do more monkey patching ?
And let our frontend as-is, or with really minimal and generic (ie. call a generic function if one is plugged with that name at the critical points) changes (so we don't have to see and think about epub_entry_transform) ?

For base and crengine, we could accept them (but make them condensed, no blank lines, opening brackets at end of line, stuff we don't care about shouldn't take that much space).

Also, if you can look at other DRMs solutions (ie. Adobe ADE/ASCM) if they would fit the model of only content encrpted, paths/filenames not), so one could do the same kind of plugin as you without needing more base/crengine tweaks ?

[pawanjay176]

Ohh you're right. I can just monkey patch loadDocument in the plugin itself. No changes needed on the frontend. Coming from a static language, monkey patching is really cool!

I'll fix up the submodule PRs tonight. Thanks again for engaging on this :)

Re the adobe stuff, I think this can work on any DRM scheme that has the encrypted contents in the zip container and just needs a key for decryption. Not completely sure how those DRMs work under the hood. I'll get back on that tonight as well.

[pawanjay176]

I checked other drms. They are a lot more convoluted and don't have great docs, but from what I could gather, the paths/filenames aren't encrypted, so this change could potentially work later for other schemes as well.
Closing this PR now as we don't need this change and only crengine and base changes should suffice.