[refactor] Assess the Logger situation and eliminate inefficiency

Enhancement Request

Eliminate the use of StringStreamLogSink

 * The use of a `StringStreamSinkLogSink`, for eg for EnergyPlus ForwardTranslator and then **regex parsing** that to derive logMessages is an abomination that should be eliminated.

Detailed Description

Regex parsing is slow, and expensive.

It also poses an extensibility/customization issue: If changing the formatter (the format of the log messages), the parseLogText gets thrown out the window.

Possible Implementation

1. The use of a pattern similar to the one I used in XMLValidator is a possibility
2. Write our end backend sink and override consume to emplace LogMessages is probably the sanest option
   • https://www.boost.org/doc/libs/1_79_0/libs/log/doc/html/log/extension.html#log.extension.sinks

Other issues

• We use a synchronized_feeding backend sink, I think we may need a concurrent_feeding one
• It seems like we may be misusing mutexes.
• This is confusing naming: https://github.com/NREL/OpenStudio/blob/dc35f3e81b01950aae134986e4bdb31e6fc18b22/src/utilities/core/LogMessage.hpp#L43
  • boost::log::sinks::synchronous_sink is a frontend sink
  • boost::log::sinks::text_ostream_backend is the backend

Context

List of references:

• Ref #3912
  • Especially this commit message: https://github.com/NREL/OpenStudio/pull/3912/commits/41430bd72ff498fb7761afcceea20dd12ca58467
• Ref #5030
• ref #5037
• Ref comments on https://github.com/NREL/OpenStudio/pull/5035#pullrequestreview-1732453420

Start by reading src/utilities/core/LogMessage.hpp and tracing the StringStreamLogSink uses described for the EnergyPlus ForwardTranslator, then compare the XMLValidator pattern and the Boost sink references. Done means agreeing on and implementing a logging path that avoids regex parsing, while addressing the stated sink, concurrency, mutex, and naming concerns.