Additions related to use of epanet from within an rtx project

[samhatchett]

This PR is part of a major code deduplication effort that is underway to improve the epanet-rtx library and its dependencies. For several years, the rtx project has used an outdated version of epanet as that team has worked through various edge cases and deployment projects. We thought it best to fork from epanet early on so as not to disrupt other development (code and community) in this sphere. Over the intervening time period, many contributions have been made to epanet that bring it almost to the point that it converges with our bifurcated version. This pull request represents the final remaining vestiges of that bifurcation. Assuming this gets merged, we can confidently remove an entire fork of epanet from github, bringing better unification to the codebase.

While I understand that the modifications here have mostly not been discussed in the project's issues threads, I humbly ask permission to suggest them here in code-form as these functions and configurations have been used in production software for some time now. Other developers may find them useful or the changes may inspire some thought about how the epanet library can be leveraged further.

Basic list of additions:

• adds Conan compatibility. Conan is a widely used C++ dependency and package management system.
• adds functions related to enabling/disabling rules and controls without altering/removing them
• adds ability to supply a client callback function for logging
• adds an api function to get information about upcoming time step events and the reasons they occur
• "friendly" error code definitions are easier to read in code.

[samhatchett]

I am posting this as a "draft" PR as I still have some more reviewing to perform before I'm comfortable with a merge. This hopefully communicates the right tone - I invite all to discuss and ask questions!

[LRossman]

I thought that pushing wholesale (multi-issue) changes without first raising them as separate issues contradicts the recommended way of making contributions to this project. I would prefer that these proposed changes be submitted as separate issues/commits so that they have a chance to be discussed and dissected more easily than when presented as one large package of changes.

[samhatchett]

@LRossman fair feedback.