Lots of assertions for debugging memory separation violations
Proxy workaround for TT #1219, see Parrot_ns_find_namespace_global
Remove debug output
Avoid calling init_world_once again for each thread

Pulled in a lot of interpreter setup code into clone_interpreter. Not
exactly pretty, but this is the only way to avoid running all the stuff
which really should only run once for the main thread. At least without
a major refactor that is. Also starting from a clean slate makes it much
easier to find leaks of unproxied PMCs to other threads.
Don't block on writing to the notifierfd.

If a threads notification pipe is full, we don't need to notify the
thread anyway since it will check all expired alarms with a single
notification.
s/Parrot_Interp */Parrot_Interp/

Parrot_Interp is already a pointer, no need for the asterisk for the
orig_interp declaration. Fixes a lot of compiler warnings (otherwise
harmless, since we only compare this pointer)
Use PARROT_IS_THREAD flag instead of testing for interp->thread_data
Flag packfile constants as shared and GC them only on the main thread

Packfiles are no PMCs so we cannot simply create a proxy for them. But
they naturally belong to the main thread, so we use the "shared" PMC
flag to tell the GC that only the main thread should mark and sweep
them.
Don't create proxies for Subs but clone them

When executing a proxied Sub, the context belonging to the foreign
interp would be used. This context for example contains globals and
namespaces.
get_global in this Sub would therefore fetch a global from an unproxied
namespace and get an unproxied global in return without any chance for
us to catch this and create a proxy.

Better to clone the sub and create proxies for all its PMC attributes
(most of all namespaces)
Run proxied VTABLE methods with the threads interp

Even read only methods can cause garbage collection (e.g. with parameter
passing). This would have catastrophic results, since a foreign thread
would be running this GC and it would find both threads' PMCs. Even
worse, the proxied interp could be running the GC at the same time.

Blocking the foreign GC is not possible without lots of locking since
even if we Parrot_block_GC_mark, the foreign interp could already be
running its GC.

Running the method with the thread's interp seems like the smaller
problem. The interps are closely related, so the data the method needs
should be available (and well suited to the caller). On the other hand
we no longer can unconditionally create proxies for all returned PMCs
since those could as well have been created by the call and would now
belong to the thread's interp. So we now check the PMC's orig_interp and
use it to decide if we need to create a proxy.

Since this enlarges every PMC by a pointer, this has some negative
impact on performance. A possible optimization could be to tell the GC
to set a flag on all newly created PMCs since we don't need to know
which interp exactly created the PMC, just if it was the current one.

We still have to block GC since during the call foreign PMCs might be on
the C stack which should not be handled by our GC.
Lock the proxied interp while scheduling a task

Scheduling a task could cause garbage collection. To be able to savely
disable the GC the proxied interp must be in a known state, so we have
to lock it. Same mechanism is already used for thread interps. Just do
the same for the main thread.
Don't exit a thread if no tasks are running

Keep threads running even if no tasks are in the queue since the main
thread may schedule new tasks any time.