Model configuration and mechanism generation

[rs028]

From the point of view of the user only the model configuration and output should be considered. Everything else should remain under the hood.
The user-relevant parts are:

1. the *.config and *.parameters files in model/configuration/.
2. the chemical mechanism (.fac) and customRateFuncs.f90 (optional) which are pre-compiled into a shared library (mechanism.so).
3. the ``model/constraints/` directory.
4. the ``model/output` directory.

The problem is with point 2, because the mechanism file needs to be converted and this generates a bunch of fortran files which do not need to be touched by the user but currently end up inside model/configuration/, which creates some confusion and potential errors.

There are several possible solutions to this:

1. in previous versions all the auto-generated files were going to src/ or obj/, and the build script was pointed there to find them. Reverting to this solutions seems a step back, however, as it mixes user-created and source files.
2. the auto-generated files can be in model/configuration/ or in model/configuration/include/ (the latter is the case after merging PR Set shared library directory #535). This also contains the shared library and it is implicit that for a given configuration the shared library is in the same directory as the .config files. This is tidier, but means that some of the files in model/configuration/ are not supposed to be edited by the user.
3. there could be a model/include/ directory where the auto-generated files are stored. The shared library and customRateFuncs.f90 remain in model/configuration/ and the content of model/include/ is all considered just temp files.
4. there could be a model/mechanism/ directory where the .fac file, customRateFuncs.f90 and the shared library are stored, together with the temporary auto-generated fortran files.

Solutions 3 and 4 are the cleanest in my mind, but require reintroducing a 4th argument to the build script and re-introduce the --shared_lib flag (it still exists, but the user can't change the value from the default). The executable arguments should not be affected otherwise. Also, I am not sure if solution 4 would still create issue with the AtChem-tools (see AtChem/AtChem-tools#4).

It would be good to have some input from users, what are their preferences and how it would affect their workflow: @AlfredMayhew @willdrysdale @bsn502.

[rs028]

With regard to going back to 4 arguments instead of 3 for the build script, it may be also the chance to implement a flag system for the build script similar to the one for the executable (#416). Any thoughts on this from the users?

[bsn502]

From my perspective, I think solutions 3 and 4 sound like the cleanest and most user-friendly options. My only concern (and this might be silly) - is there are reason behind calling the folder with all the temporary files, not to be edited by the user, "include"? If I were a new user, I may think I need to go into this folder to describe what I want to "include" in the model. Other than that, I like the idea of using flags with the build script, and having the .fac file in the model folder might be quite nice for keeping track of which mechanisms a particular model run has used.

[rs028]

Not really, it is (I think) a standard nomenclature for libraries that needs to be linked to the compiled executable. But I agree it may be a little confusing.