Track outstanding GPU work per allocation for host-accessible arrays

[maleadt]

Arrays backed by SharedBuffer or HostBuffer can be accessed directly from the CPU, so every host access has to wait for outstanding GPU work on the buffer first. #649 fixes the most visible symptom (sum/maximum returning 0) by unconditionally synchronizing the current task's stream in scalar getindex/setindex!. That is correct for the single-task case, but has a few problems:

• Cost. Every element access now does a device() and global_stream task-local lookup plus a zeCommandListHostSynchronize (and a queue sync if oneMKL was used). A CPU loop over a shared array, which is the main reason to make these arrays host-indexable, turns into a driver call per element.
• Other tasks. Only the calling task's stream is synchronized. Work on the buffer submitted from another task, or to a user-created queue, is not waited for.
• Other host accesses. Taking a CPU pointer through unsafe_convert(Ptr{T}, x) (unsafe_wrap(Array, a), passing a to a CPU ccall, ...) doesn't synchronize at all. The host↔shared unsafe_copyto! methods each synchronize explicitly to compensate.

How CUDA.jl does it

CUDA.jl wraps every allocation in a Managed object (CUDACore/src/memory.jl) that records the stream that last used it and whether that use has been synchronized:

• Converting the array to a device pointer (convert(CuPtr, ::Managed), i.e. every kernel launch or copy) calls take_ownership!, which records the current stream and sets dirty = true. Switching to a different stream first syncs the previous owner.
• Converting to a host pointer (convert(Ptr, ::Managed)) calls maybe_synchronize, which syncs the owning stream only if the allocation is dirty, and then clears the flag.

Scalar indexing goes through pointer(x, I; type=HostMemory), so it needs no explicit synchronization: the first access after GPU work syncs, later ones cost a lock and a Bool check. Because the owning stream is synchronized rather than the caller's, cross-task use works as well. (There's also a captured flag that forces synchronization for memory used during stream capture, which has no oneAPI equivalent yet.)

What oneAPI.jl would need

oneArray.data is a DataRef around the raw oneL0 buffer, so there's no place to keep this state. Roughly:

1. Wrap buffers in a small mutable object holding the owning oneStream and a dirty flag (plus a lock), at least for host-accessible buffers.
2. Set ownership and dirty in unsafe_convert(::Type{ZePtr{T}}, ::oneArray), synchronizing the previous owner when the stream changes.
3. Call maybe_synchronize in unsafe_convert(::Type{Ptr{T}}, ::oneArray), and drop the explicit synchronization from scalar indexing and from the host↔shared unsafe_copyto! methods.

Tests should cover broadcast followed by scalar indexing (not just reductions) and a kernel launched from another task and read from the parent.

Possibly related: #458.