Adopt a proper logging framework throughout SAW, Crucible, etc.

[atomb]

Controlling what output we get from SAW, Crucible, What4 and related libraries is difficult because they all use different mechanisms for reporting progress, errors, etc. We should adopt a single library for logging within all of them.

[robdockins]

I have some concrete thoughts on various standardization ideas to kick off the conversation and start some bikeshedding:

1. We should avoid using String as much as possible, and prefer to use Text in pretty much every situation instead.
2. As I recall, we settled on the prettyprinter library as a strong candidate for standardization, pending some performance testing. We should standardize on some pretty printer library and prefer to use it for all human-facing output methods.
3. I've come around to the idea of using URIs as a standard format for naming things we'll want to refer to in configurations and such (configuration options, logging concepts, classes of undefined behavior, parts of programs under analysis, etc). The "scheme" part of the URI gives us a way to identify namespaces, the path components give just enough structure to be useful without painting us into a box. They already have widespread printing and parsing support in many languages and a reasonable human-facing syntax, complete with escaping rules if necessary. The modern-uri package seems to do everything that's required here on the Haskell side.
4. Logging should be arranged around a logging "concepts" arranged into a hierarchy with a human-readable names (using URIs as above), and individual messages should have a severity which is one of exactly three things: error, warning, or info. Logging filters can set verbosity levels for options and groups of options to levels from 0 to 3, where 0 means silent, 1 means print errors only, 2 means print warnings and errors, and 3 means print everything. Top-level executables will install a default logging verbosity settings which can be overridden via some mechanisms to be decided. Ideally, we would be able to have multiple separate logging filters and output destinations installed simultaneously, so one can, e.g., print copious debug information to a file while still having reasonable human-readable output on stdout.
5. We should migrate away from using error and fail in every instance we can, preferring instead to call panic for internal errors arising from programming bugs, and throwing exceptions or using datatypes incorporating error conditions for errors we expect to be triggered by user input or environmental conditions.

[kquick]

I would like to propose we use the Lumberjack logger module, which allows for structured logging as well.

[chameco]

#476 and #138 are related to reducing usage of error / fail, for reference. I did some work earlier this year in #685 to migrate away from fail toward (slightly) more specific exceptions in saw-script, but there are still a lot of cases in dependencies that we'll need to think carefully about. Making sure that we take a standard approach everywhere and documenting the convention seems very useful.