Logging foundation

[Enet4]

As defined in the roadmap, some situations while working with DICOM data may not be critical to impose a soft error or panic, but should still be called out in some way. Logging comes to play as a non-invasive mechanism to report abnormal situations which do not impede the process, but may bring other issues along the way. As such, it is still relevant to provide this information to developers and to end users of CLI tools.

The two phases for fulfilling this issue would be:

• Decide on a logging API for all library crates (as a façade to an actual logger implementation which can be decided by dependents). I believe this would be narrowed down to choosing between log, slog, or tracing.
  • tracing it is.
• Choose a logging implementation for each existing CLI tool (dicom-dump, dicom-scproxy, and so on). One that prints to stdout/stderr would suffice.