Use string instead of integer to select WarpX algorithms

[RemiLehe]

Overview

This PR modifies the way in which users choose the algorithm in the input script: instead of using integers, users now enter a string - which is often more meaningful to them. Note that this will break backward-compatibility ; previous script will abort with an error message explaining that an integer is not a valid algorithm.

Internally, WarpX still uses integers, as a switch for different algorithms. (This is mainly for compatibility with PICSAR, and other Fortran routines.) Therefore, at initialization, the string entered by the user is matched to the appropriate integer using maps. (These maps are not used anymore, after initialization.)

This PR ensures that:

• The code checks that the user entered a valid string, and aborts the code otherwise, while printing a message that lists the valid strings.
• If the code was compiled for GPU: options that do not work on GPU can never be selected.
• A reasonable default is chosen, if the user does not explicitly select an algorithm in their input script.

When reviewing this PR

There are a lot of files changed, because all the input scripts had to be modified. However, when reviewing this PR, I would recommend to look at the following files, in the following order:

• parameters.rst : documentation explaining the new way in which the user enters the algorithm
• WarpX.cpp: initialization of the algorithm integers, calling the function GetAlgorithmInteger
• WarpXAlgorithmSelection.cpp: definition of GetAlgorithmInteger
• WarpXAlgorithmSelection.H: enumeration defining integers for compatibility with PICSAR/Fortran.

[atmyers]

I find that I need to #include <map> here to compile this on Summit.

[RemiLehe]

OK, thanks. I'll add this.

[atmyers]

You could use std::transform(algo.begin(), algo.end(), algo.begin(), ::tolower); here so that users could put either Boris or boris, say.

[atmyers]

Should this be "field_gathering"?

[RemiLehe]

Ah, yes indeed! Thanks for catching this!

[atmyers]

Is it worth distinguishing between things like the CKC field solver, will give the correct answer with USE_GPU=TRUE but will be slow because the routines aren't offloaded, and things like vectorized deposition, which will just crash? Right now the code will abort if CKC is selected and USE_GPU=TRUE.

[RemiLehe]

I think that it's okay to prevent users from using routines that will run on the CPU. (We don't want them to use them by accident without knowing that they will be slow.)

Regarding CKC in particular: we could easily add the required acc directive in picsar, and edit the WarpXAlgorithmSelection.cpp accordingly.

[RemiLehe]

@atmyers Thanks for your comments. I addressed them, and also added the required OpenACC directives for the CKC solver to work on GPU, on the PICSAR side.

In addition, I incorporated the changes from #170, so that the automated tests pass.
So please merge #170 first.

[RemiLehe]

@atmyers I think the PR is ready for merging.