Store the frontend task object in the REPL struct.

[maleadt]

This makes it possible for GPU back-ends to allow so-called scalar iteration (element-wise copies of elements, often triggered by iterate in generic fallbacks, normally disallowed because it indicates that processing is happening on the CPU) in the REPL, where it is often triggered by show methods visualizing output.

If this isn't too controversial, I'd like to get this in 1.9 because it is a significant QOL improvement to GPU users.

X-ref JuliaGPU/GPUArrays.jl#446

[maleadt]

@KristofferC and @rfourquet seem to have made the most changes to the REPL sources lately, so pinging for review.

[rfourquet]

I must admit I don't understand the problem this would solve, so I can't really comment. This change seems fine though, although in-code comments and/or tests would be welcome such that it's not reverted accidentally in a future commit.

[maleadt]

So GPU arrays need all their operations to be implemented using vectorized functions, which dispatch to a GPU kernel. Base however has plenty of fallback functions that perform element-wise operations (think for loops, etc). That's why we generally disallow getindex and other scalar functions, throwing an error instead.

There's one big exception to this: the display stack. We don't want to have to reimplement every show method to avoid triggering getindex, especially because performance doesn't matter there, and also because it's hard in the presence of array wrappers (view(::GPUArray) isn't a GPUArray). So ideally we want a simple way to allow scalar iteration for display code. We haven't found a way to do this, but most of the time users only display arrays from the REPL, so with this PR we can do (pseudo-code):

function getindex(::GPUArray, idx...)
    current_task() == Base.active_repl.frontend_task && return
    error("scalar getindex not allowed")
end