Mostly addressing #1400, but a few other things in there too; it was kind of a long steady accumulation of various things, I've tried to chop it up into a few commits as best I could.

They're significant library changes, and I don't like making changes that break compatibility with any stand-alone scripts out there, but I think there's strong justification for making the changes. After all, how many times have we modified the C++ library code in getting to the point we're at now?

I'll try to enumerate everything of interest here for comments. Not going to be merging this PR quickly, I should probably be implementing more tests before accepting such large changes; but I wanted to open the proposed changes up for discussion.
(Also I need to get this stuff out of my head so I can focus on more pertinent demands...)

1. Completely changed how executable script files invoke the core application library.
   Previously there was a set of compulsory library functions that needed to be executed in the correct order, e.g. app.initialise(), app.parse(), app.complete(). Now, one defines two functions: usage() and execute() (couldn't have usage() and run() like in C++, since the latter would clash with the run module). After definition of these functions, app.execute() is invoked. app.execute() then sets everything up, using the inspect module to find those two defined functions and run them when appropriate.
   The biggest advantage of this is that it enables the use of exceptions. Instead of calling app.error(), library functions will throw a custom MRtrix3 exception, which can either be caught by the script programmer, or result in similar error message & cleanup behaviour as app.error(). This substantially improves the capability for scripts to catch when things don't quite work as intended and adjust appropriately.
   run.command() gets its own exception, which includes all information about the command and the stdout / stderr contents. This means that the error messaging and cleanup can occur entirely within app.execute() when the exception is called; as opposed to the current solution, which is partially managed by run.command() writing a text file that app.complete() then reads, which is kinda clunky.

2. Moved some basic capabilities, e.g. listing available MRtrix3 binaries / importing the config file(s), to __init.py__. Anyone using the library functions but not invoking the app module in its entirety should still be able to access this information.

3. Changes to run.command() to support multi-threaded usage.
   Note that this required the use of tempfile.mkstemp() rather than tempfile.TemporaryFile() due to an apparent race condition in the latter on Python3 on Windows (not present on Windows Python2; not yet tested on Linux). This is despite the Python documentation suggesting that TemporaryFile() uses mkstemp()... The side-effect of this is that the stdout / stderr contents of executed commands are written to files in /tmp/ and deleted after they are read; there could potentially be issues with users not having write access to that location and/or accumulation of stale files due to cleanup issues.

4. Porting of foreach to Python. In addition to appearing in the online documentation, this also means that the terminal will present a simple progress bar showing the execution of however many instances of the command are run, and at completion only invocations that failed, along with their stdout / stderr contents, will be printed. Note that the command-line usage is fractionally different to the current bash script.

5. New script responsemean, which has substantial changes from the basis average_response, but I think the name is more consistent with the rest of MRtrix3. In addition to making use of the libraries (and hence appearing in the online documentation), having better error messages, and being a little more Pythonic in places, the (default) averaging process is different, as proposed in average_response: De-mean before averaging #1096.

6. Merge file and path modules into fsys. Really didn't like having to use pylint directives to hide the fact that a Python built-in was being over-ridden.

7. Much nicer terminal feedback when running population_template, as you don't get humongous run.command() strings when running e.g. mrmath across all subjects (implemented the solution proposed in this comment in scripts: allow list input to run.command #928).

Partially addresses #692.
Hoping that #927 can be closed, but point 3 may raise other issues regarding the solution.
Closes #928.
Closes #1096.
Closes #1275.
Closes #1338 (script author can simply catch the exception along with stdout / stderr contents).
Closes #1377 (command returncode is returned in exception raised by run.command()).
Closes #1400.