Add GPU to CPU RPC mechanism

[ajuvercr]

This tries to enable generic syscalls in GPU abstractions, with a main focus on speed and transparency.

First enable better printing than @cuprintf, later multiple options are possible, like reading/writing to files.
If performance is good enough this can be used for malloc to improve memory management.

This could be a baseline to accept dynamic Julia errors, as unsupported type etc.

Fixes #440

[jpsamaroo]

I assume the intent of this PR is to implement a flexible GPU-to-CPU RPC system, like AMDGPU's hostcall? If so, my recommendation is to also provide a buffer where you can pass arguments from the GPU, and return results from the CPU. This would allow you to instead use the flag's value for locking the buffer and communicating syscall state (idle, device-held, host-held, etc.), and you could then pass and return arbitrary bitstype Julia objects. Such a mechanism has been working well for AMDGPU's printing and memory allocation infrastructure (although it's not yet multi-wavefront safe, but that will be fixed). We also have one flag+buffer per executable and per hostcall type, so our kernels will be able to concurrently utilize different hostcalls without contention.

[jpsamaroo]

Also, please feel free to study and steal from the hostcall implementation here: https://github.com/JuliaGPU/AMDGPU.jl/blob/master/src/device/gcn/hostcall.jl

[maleadt]

That won't just be fragile, right? https://stackoverflow.com/questions/23193151/atomic-operations-in-cuda-kernels-on-mapped-pinned-host-memory-to-do-or-not-to
Maybe some kind of ring buffer where the CPU just passively reads would be safer? That may only require atomicity from the GPU's side.

[maleadt]

This makes kernel launches synchronous? That's not OK.

[maleadt]

#3243