Call the setdefault_with factory without holding the lock

[Malkiz223]

Closes #67

The factory used to run while the internal lock was held, and __traverse__ takes that same lock, so a GC pass inside the factory froze the process. Now the key is looked up under the lock, the lock is dropped, the factory runs without it, and then the lock is taken again to re-check the key before inserting. Same change in all seven cache types, plus the doc strings.

One behaviour change: if two threads miss the same key at the same time, the factory can run twice. The value inserted first stays in the cache and is returned to both of them, so no caller ends up holding an object the cache does not have.

The test sits in the shared mixin, so it runs for all seven types. It does the call in a child process on purpose: a deadlock keeps the GIL, so a watchdog inside the same process would never fire. Without the patch the test fails with "never returned" instead of freezing the whole run.

1004 passed, 6 skipped. The suite also stopped hanging: 4 freezes in 9 runs before, 5 clean runs out of 5 after.

[awolverp]

I hadn’t thought of something like that
thank you for finding the problem and fixing it