Fix #63 #66, supersede #67: Wrap Python exceptions into custom InternalPythonError

[qwenger]

Fix #63, fix #66.

Supersedes #67. As proposed over there, this stores Python exception into a JS object rather than globally.

On the QuickJS side, the object uses as an opaque pointer to store the Python exception.
On the JS side, the object has constructor InternalPythonError that extends InternalError and has the message property set to Python call failed.
On the Python side, the exception type is JSPythonException, a subclass of JSException. Its __cause__ is set to the exception originally triggered, which is a pretty clean way to keep track of it.

The code has a few "not so nice" areas, but for which I did not find anything nicer:

• The finalizer (that decref's the stored Python exception when destroying the wrapping InternalPythonError) has to do a special check of the thread state, because it is both called from inside prepare...end_call_js and prepare...end_call_python.
• A custom constructor for InternalPythonError was needed, because I did not see a way to use the parent constructor (InternalError).
• To get a proper stack for the JS error, a standard InternalError is first raised, then catched directly and its stack property transferred over to the InternalPythonError.
• Similarly, the Python exception is fetched and restored to set its cause (but that's pretty standard).

[qwenger]

The check_memory.py script does not notice any issue (other than the spurious ones from threading, which also show up in master).

[qwenger]

One question is also whether we would like to expose the JS Internal(Python)Error via the JS(Python)Exception on the Python side, e.g. as an Object bound to JS(Python)Exception.raw.

Or better yet, make JSException subclass of Object and directly encapsulate the JS error inside it?