[TASK] Be able to direct output somewhere other than sys.stdout

Issue Description

Is your feature request related to a problem? Please describe. Due to an implementation detail in the MessageHandler class, users are unable to redirect output to somewhere other than sys.stdout. Adding the ability to redirect that output would facilitate development of other user interfaces and generally allow users more control over how and where the text output of their RAVEN case is directed.

Describe the solution you'd like The function in question in the MessageHandler class is this one:

  def message(self, caller, message, tag, verbosity, color=None, writeTo=sys.stdout, forcePrint=False):
    """
      Print a message
      @ In, caller, object, the entity desiring to print a message
      @ In, message, string, the message to print
      @ In, tag, string, the printed message type (usually Message, Debug, or Warning, and sometimes FIXME)
      @ In, verbosity, string, the print priority of the message
      @ In, color, string, optional, color to apply to message
      @ In, forcePrint, bool, optional, force the print independetly on the verbosity level? Defaul False
      @ Out, None
    """
    verbval = self.checkVerbosity(verbosity)
    okay, msg = self._printMessage(caller, message, tag, verbval, color, forcePrint)
    if tag.lower().strip() == 'warning':
      self.addWarning(message)
    if okay:
      print(msg, file=writeTo)
    sys.stdout.flush()

The issue is the default value writeTo=sys.stdout reverting overwrites of sys.stdout to sys.__stdout__, and there is no opportunity through functions higher up the call stack (e.g. in the MessageUser methods) to specify a different value for that argument.

Through offline discussion with @PaulTalbot-INL and @joshua-cogliati-inl, two paths forward have been proposed:

Simply remove the option since it's unused and apparently only partially implemented. This would allow Python scripts running RAVEN as a module to overwrite sys.stdout to redirect output to a desired location.
Store writeTo as an instance variable (e.g. as self._writeTo in MessageHandler), which can then be referenced throughout the class to direct output to the appropriate place.

Some initial work leads me to believe option 1 is the better option. When using RAVEN's command-line interface, stdout and stderr can easily be captured and directed to files through additional command line arguments. The real benefit of addressing this issue is for use of RAVEN from a Python environment, in which case, direction of output can once again be handled externally more simply than internally within MessageHandler.

Describe alternatives you've considered See the above discussion.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

[x] 1. Is it tagged with a type: defect or task?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[x] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

idaholab / raven