Closes #1259, #1625, #1532 and I believe also #9 (see discussion below)

Changes:

• Logging to files is now by default disabled (still logs warning and above to console stdout) and users need to manually enable it or set an environment variable so that it is enabled automatically on startup (more below)
• PyFluent loggers now have the pyfluent prefix to avoid conflict with other loggers
• All logging output now goes to a single file, example:
  Logging file example

  
• Added support for PYFLUENT_LOGGING environment variable, which we can use so that we don't have to change logging levels manually and so that logging is automatically set to DEBUG (or any other level you want) for development/debugging
• Added convenience functions list_loggers() and set_global_level() (see documentation in the item below)
• Add documentation:
  User guide index

  
  
  API reference index

  (this isn't directly related to Fluent's API, but couldn't think of a better place in the current docs, please let me know of any suggestions)
  

Recommendations:

• I think using root logging calls such as logging.info() or logging.warning() is something we should avoid and could conflict/cause issues with other packages or something that users have set up themselves, using the custom defined loggers is better in every way that I can think of, so logger=getLogger('pyfluent...'); logger.info() etc
• Use print() when the objective is to output non-error information to the Python console directly for the user to see or when it is an important non-error message and just logging to files is insufficient (we can set up additional logging for different combinations as well if necessary)

In regards to #9, the only scenario where no useful information or silent failing was being returned to the user that I could think of, and based on my experience as this was an issue for me too, was when running Fluent on containers, where it was failing completely silently with no logs or console output at all to help. My suggested fix (relevant lines below) is to set the docker image to run on the specified work directory that is also mounted on the container host system. In this way, the user, which has access to the host system but not necessarily the guest docker container files, now has access to the Fluent automatic transcript output too, which is typically what is needed to better debug launch issues. I have also changed all the docker run shorthand args for their full names (check the other lines around the ones linked below), as I believe this makes them much clearer and easier to work with. Please let me know if I missed any scenarios where logging and workdir/transcript location changes aren't sufficient.

While this is fresh on my mind, please let me know if you have any questions, can think of any suggestions or ways in which logging would be more useful to you for development or any other purposes.