Consolidate warnings, suppression and deduplication

[fischeti]

Warning collection

This PR collects the current warnings system into a monolithic diagnostic::Warnings enum, which has the following benefits:

• Make it much easier to keep warning codes coherent which are also used to suppress warnings
• Allows for easier reuse of warnings without duplicating the warning message
• Consistent formatting of Warning messages
• Additional help messages to guide the user to solution to the warning.

Suppression handling improvements

Additionally, the current warning and error suppression system has been improved a bit. A global resp. static Diagnostics handler now takes care of suppression. It is initialized in the beginning with the user defined suppressed warnings. This cleans up the code since suppress_warnings does not need to be passed around anymore, and whether a warning is suppressed is checked automatically behind the scenes when a Warning is emitted. Further, the Diagnostic handler keeps track of emitted warnings and deduplicates them to avoid redundant warnings. It not only differentiates between the type of warning but also it's content (e.g. SomeWarningAbougPkg for pkg1 is treaded as different than SomeWarningAboutPkg for pkg2).

Warning formatting

The new formatting of warnings and help messages is shown below:

warning: This is a warning without a code and without a help message.

warning[W03]: This is a warning with code "W03" and without help message
 
warning: This is a warning without a code, but a help message
 ╰─› help: This is the help message
 
warning[W02]: This is a warning with code "W02" and a help message
 ╰─› help: This is the help message
 
warning[W06]: This is a warning with code "W06" and multiple help messages (if separated by "\n")
 ├─› help: This is the first message
 ╰─› help: This is the second message

(in reality the warnings are also colored properly)

New crates adoption

Two new crates were adopted to reduce boilerplate code and derive warning/help messages, error codes and severity from procedural macros:

enum Warning {
    #[error("This is the warning message containing {some_data}")]
    #[diagnostic(code(W42), severity(warning), help("Fix something in {some_data}"))]
    SomeWarning { some_data: String }
}

miette

This crate uses the #[diagnostic] macro to implement traits for the specified enumeration variants that allows it to call help(), code() and severity() on an enum variant. miette can do a lot more and is mostly used for nice annotations of source code. In the case of Bender this is less relevant since it is not a compiler that reads source code. It could in theory be used to annotate wrong Bender.yml files, but this is a bit overkill at the moment, and our current YAML parser does not return positional information of fields in the source.

thiserror

The second crate uses the #[error] macro to derive the Display trait for the warning message. At the moment, we are not using thiserror to its full extend. It also implements automatic Error conversion and chaining, which will be implemented in a separate PR to make the review easier.

TODO:

• Some warnings currently have the same warning code. This is not a problem for miette, but suppression is impacted potentially.

[micprog]

I added some minor things, but overall LGTM! I really like the updated output and the cleaner handling of suppressing warnings!

There are some warnings that should actually be help information for an error, which are currently noted as TODOs. Thanks for doing this, I think it's best addressed in an upcoming PR.

[micprog]

LGTM 👍