Refactor 'Errors' SQL output and make it consistent

Issue overview

This is really a feature request, but I'm posting it here rather than uservoice because I'd like to discuss it, and maybe even help implementing it.

First, when throwing an error (either in the SQL or eplusout.err) the ErrorMessage is not consistent accross the board, more often than not it includes the Procedure (function) that threw the warning, other times it doesn't. Making it consistent would be a nice touch.

Second, currently the SQL 'Errors' table has the following structure: ErrorIndex, SimulationIndex, ErrorType, ErrorMessage, Count.
It would also be beneficial if the SQL table could have at least one more additional column (but ideally more than that) to include some information about the error (eg; 'PlantLoop'), and perhaps the specific component (eg: 'DHW LOOP'). This would make post-processing and analysis of errors more convenient and robust. (Using the eplusout.err file can make it hard to classify/analyze the warnings and errors when you have a ton of them as you cannot clearly see which one are most important/preponderant)

Details

The ErrorMessage itself is usually structured in a way that is informative, eg:

ProcessScheduleInput: ScheduleTypeLimits="CONTROLMODE", Unit Type="CONTROLMODE" is invalid.
Plant Loop: DHW LOOP Demand Side is storing excess heat the majority of the time.

More often than not, it starts with _Function_: which is a very useful indication of which routine threw the warning/Severe/fatal. It would be useful if the 'Errors' table could have a an additional column (called "Routine" or "Module" or "Procedure" or whatever) that would store this information and make it available for easy post-processing.

Having sub information on the component type and component named responsible for the warning would be useful too, perhaps the Module that contains the function too.

This would also require adding information for some other cases where the message doesn't include it, for eg:

Calculated design cooling load for zone=THERMAL ZONE: SPACE 101 is zero. Check Sizing:Zone and ZoneControl:Thermostat inputs.

Reading the message, I know it's probably coming during zone equipment sizing (here really), but the format still isn't consistent.

I would also add one last column, to show when the error occurs (InputProcessing, Warmup, Sizing, Simulation, could use the DataGlobals flags such as DataGlobals:DoingInputProcessing, DataGlobals::WarmupFlag, DataGlobals::DoingSizing, DataGlobals::KickOffSimulation etc)

For the three above examples, maybe we could do something like this:

Thoughts?

Checklist

• Ticket added to Pivotal for defect (development team task)
• Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)

Start with the SQL Errors table structure described in the issue and the referenced src/EnergyPlus/ZoneEquipmentManager.cc location. Review how ErrorMessage values and DataGlobals phase flags are produced, then determine the schema and message-format changes needed. Done means the requested error context is consistently available for SQL post-processing and the proposed examples are represented.