This closes #507, #673, #666

First to demonstrate the log speed (this new one is FAST), and to maintain the functionality of the existing code (a whole-system refactor is not super duper desirable), and to incorporate the remaining elements of the log tool.

Remaining elements:

• Persistent token for operation. this would identify the specific operation that's being done (build/export/export just one...etc.) and would be used to identify the relevant log entries to grab. Doing this would make it so if the log didn't get deleted each time we could grab relevant info. This also makes it so if we somehow perform more than one operation at once (automated building), or where the addin is called from two different Access instances you could perform an operation on both instances at once without log entries getting mixed up.
• log import/export for selected operation token
• clsOptions
  • Log Level (currently natively part of the new log class, but is not implemented in options) (Added to options)
  • DisplayLogLevel
  • Add Upgrade Options for ShowDebug
  • [-] Remove ShowDebug as an option.
    • [-] ShowDebug is used 32 times. Suggest setting those use cases to an event level of eelDebugTrace, eelDebugEvent, or eelDebugInfo
    • Alternately: could just create an option that is If Options.DisplayLogLevel < eelNoError Then Options.ShowDebug = True (this seems the easiest way to handle it, actually)
  • Set LogLevel and DisplayLogLevel after Options are loaded
  • Whether logs are persistent or transient (per export) (default to not persistent)
    • Replicated existing method
  • What fields are logged (meta data)
    • Username
    • Computer name
    • Operation and Operation State (captured in clsErrorInfo)
    • [-] others?
    • Current file being built
    • Addin Path?
  • Add persistence mode (defaults to off).
  • Determine how to parse the XML to a human readable output.
    • [-] Do we need to save the color/HTML the console displays?
    • [-] Can this be easily parsed to MarkDown?
    • Removing some HTML Tags but not all seems to do nicely.
• frmOptions:
  • Change Show Debug Checkbox to dropdown option for DisplayLogLevel.
  • add dropdown for LogLevel
  • Add option for persistent log (future). Current operation method will make this perform the same as currently happens (non-persistent logs).
• Get connection to the addin corrected; currently will only call the local program, but getting a connection to the addin shouldn't be too bad.
• Log persistence; the current tool exports the log to an xml file; need to implement a tool to pick that log back up into the log from the last exports; once you close the addin (from the built database) the addin resets to the previous state. To make the log persistent, we need to either reimport the previous values OR append them to the previous export.
  • It turns out the log is persistent when a table in the addin is used.
• Ensure backwards compatibility with previous log
• Determine how to handle "Private" log information that would be very valuable to a internal dev team, but should not be sent out. These would be especially informative for projects that share a dev space, and / or have a runner that's triggered by merge events.
  • for now, defaulting private values to Off, and exposed an optional setting to log those.
  • Username
  • Computer Name
  • others?
  • Use a command SQL statement to select only relevant columns (aka don't export the sensitive columns where desired)
• Auto-build the temp file and external log (to avoid bloat on Addin file directly).
• Build cleanup for temp file and external log file (ACCDU).

This first PR is to build out others, create discussion, and have some review before we go forth. I've implemented it here as a ridealong to demonstrate feasibility and speed impacts (in my testing, it did not impact speed of export or build at all) and provided a ton more information and time stamp detail than I had.

The log also allows us to set the log level and thus keep the log a lot cleaner when users don't need ultragranular detail. For instance, if you're troubleshooting an export, you can set the log to log everything, even Debug Tracing. If you're in production, and you just want to know if warnings or more happen, you set it to warning.

Let me know what you all think!

If this initial implementation looks ok, I will refactor the rest of the clsLog2 class into the new one, but wanted to start off by showing a proof of concept.

@joyfullservice @josef-poetzl @bclothier anyone else?