gc_mark_task improvements

[vtjnash]

this is more careful in gc_mark_task given that part of the jl_root_task stack may not have been moved (also don't bother copying some of the top of it)

with the recent changes to julia_init, this scenario was possible, if julia_init was called from a lower stack frame then any call to jl_apply. this only applied to embedded context, since this doesn't happen for repl.c. however, since it can handle it, i also make use of this to skip copying the first 1024 bytes of the root task.

@JeffBezanson done as a PR so you can check that my >= conditions are correct (with the assumption that the stack grows down)

[vtjnash]

(travis failure appears to be due to homebrew spending it's allotted hour trying to build gcc from scratch, rather than actually testing julia)

[vtjnash]

@JeffBezanson bump. thoughts?

[JeffBezanson]

I don't think this pattern of use should be supported. You need to initialize julia cleanly before calling jl_apply. The amount of duplicate code here for marking the stack is not a good sign.

[vtjnash]

You need to initialize julia cleanly before calling jl_apply

i'm not sure what that means. this patch helps eliminate any dependency on jl_init not being called at a high enough stack location to cover all jl_apply calls.

the code duplication was a bit of an optimization so that non-root tasks didn't need quite as many branches

[JeffBezanson]

What it means is that I'm perfectly comfortable with having a dependency on jl_init being called higher on the stack than any jl_apply. I don't want to commit to supporting this very questionable use pattern unless it's clear that doing so is important.

[vtjnash]

ok