add batched fields for better GPU usage

[marius311]

This adds "batched" Flat fields which behave just like normal fields but actually store several "batches" of fields at once. The motivation is to speed up GPU code, which is currently only using about 20% of a Tesla V100, due to having to wait on results of FFT kernels. Since we can't speed those up, the solution is to just do more of them in parallel. However, we only get the full speedup if we actually batch the field data together so kernels can efficiently go through it all at once, hence batched fields.

You can create batched fields in several ways:

FlatMap(rand(128,128,4)) # a batch of 4 128×128 fields
batch([f,f,f,f]) # put four non-batched fields `f` together in a single batch-4 field
batch(f,4) # same as above but data not actually copied four times

All code pretty much works transparently on batched fields as it does on normal fields, but just does everything in batches. This includes everything up to posterior gradients, sampling, etc... The only difference is that operations that return a scalar now return a BatchedReal (which itself can be added, multiplied, etc... as if it were a Real):

julia> dot(FlatMap(rand(128,128,4)), FlatMap(rand(128,128,4)))
BatchedFloat64[4114.738009871811, 4105.554880583013, 4109.014277485975, 4109.830420691169]

On a Tesla V100, some timings for a 256×256 Float32 mixed posterior gradient:

┌────────┬───────────┬─────────┐
│ Time   │ Batchsize │ Speedup │
├────────┼───────────┼─────────┤
│ 120 ms │         1 │    1.0× │
│ 192 ms │         2 │    1.3× │
│ 196 ms │         4 │    2.4× │
│ 217 ms │         8 │    4.4× │
│ 345 ms │        16 │    5.6× │
└────────┴───────────┴─────────┘

Looks like the sweet-spot for per-gradient speed-up while not hurting overall sequential runtime is somewhere near batchsize of 10 and we get about a 5x speedup.