Add option to put the 3D array in pinned memory so it stays on the host

[MaxThevenet]

This PR adds option to allocate the 3D field array on pinned memory, so it stays on the host. This should generate H2D and D2H copies of slices, which is slower, but would allow to run a large problem (that doesn't fit in GPU memory) on GPU.

NOTE: This has not been tested for accuracy yet. For all slices, in verbose = 1 mode, I get messages like islice: 6 n_iter: 1 relative B field error: 0, so I am not sure this is correct. Hence, this would need more testing before merging.

• Small enough (< few 100s of lines), otherwise it should probably be split into smaller PRs
• Tested (describe the tests in the PR description)
• Runs on GPU (basic: the code compiles and run well with the new module)
• Contains an automated test (checksum and/or comparison with theory)
• Documented: all elements (classes and their members, functions, namespaces, etc.) are documented
• Constified (All that can be const is const)
• Code is clean (no unwanted comments, )
• Style and code conventions are respected at the bottom of https://github.com/Hi-PACE/hipace
• Proper label and GitHub project, if applicable

[SeverinDiederichs]

This looks great! Your input script must have been bad, if the error is 0 everywhere it basically means that nothing is happening and all quantities should be 0.

I tested it on my GPU and

1. it gives the correct result
2. it uses indeed less memory on the GPU:
   Using development:

Total GPU global memory (MB) spread across MPI: [7973 ... 7973]
Free  GPU global memory (MB) spread across MPI: [5162 ... 5162]

Using host_device

Total GPU global memory (MB) spread across MPI: [7973 ... 7973]
Free  GPU global memory (MB) spread across MPI: [6058 ... 6058]

[SeverinDiederichs]

As we found out, there is an issue with IO, but without IO it works great. This is a big step towards high-resolution simulations on a single GPU.