CRE: avoid assert failure in sub-processes

[poire-z]

Will allow frontend to disable CRE finalizers when running code in a subprocess and explicitely exiting quickly without any proper cleanup.
See #1679 (comment) and followups.

Buddy frontend addition:

--- a/frontend/document/credocument.lua
+++ b/frontend/document/credocument.lua
@@ -116,6 +116,15 @@ end
 function CreDocument:engineInit()
     if not engine_initialized then
         cre = require("libs/libkoreader-cre")
+
+        -- When forking to execute any stuff in a sub-process,
+        -- as that stuff may not care about properly closing
+        -- the document, skip cre.cpp finalizer to avoid any
+        -- assertion failure.
+        require("ffi/util").addRunInSubProcessAfterForkFunc("cre_skip_teardown", function()
+            cre.setSkipTearDown(true)
+        end)
+
         -- initialize cache
         self:cacheInit()

Pinging @benoit-pierre .
(A mix of the 2 ideas: a rough "skip tear down", but with some generic way to add/remove funcs. Would be more complicated to add stuff referencing the document to do setCacheFileStale() and close() - and I didn't really like the idea of having to do that and I prefer the carefree approach.)

---

This change is 

[benoit-pierre]

This work for this use case, but if we generalize it, e.g. for use in the coverbrowser plugin, we would really need a pre-fork hook: you don't want to keep using the same sqlite database connection concurrently in the child process.

[poire-z]

you don't want to keep using the same sqlite database connection concurrently in the child process.

Well, for this coverbrowser sqlite connection, if this was the case, I would consider it an oversight of my part. And I would consider this a "business" thing to be solved by CoverBrowser code (for its own subprocesses where we may really do use the same db connecion), and it would not have to be handled generically globally for other kinds of subprocesses (that we know that they should not do any sqlite queries on this db connection, so no harm letting it be a handle on the sqlite data file).

But it looks like we do close that DB connection:
https://github.com/koreader/koreader/blob/31c28378e7d9566969697968f6c745b14089be2a/plugins/coverbrowser.koplugin/bookinfomanager.lua#L679-L703
That is in the parent process, before launching the task in a subprocess.

I may not have worried more at the time, because from my experiences and investigation of sqlite from 10 years ago (things may have changed since?): as sqlite should work in many individual processes without anything shared in between, it can't rely on things cached in the process: it has to re-read everything from the db data files to be sure to work on not stalled data; it only locks pages when actually running a query or update, or when starting a transaction, preventing other processes from getting locks on these same pages (at the time, I think it was not even at the block/page levels, it was a generic lock on the database file). When not in a transaction, the "sqlite db connection" may just be an innofensive file handle with nothing pending on it.