Debugging tooling for configurable bridge rules

[jarhodes314]

The configurable bridge rules (once #3918 is merged) will be quite powerful, but also therefore somewhat possible to screw up. As a result, I think we need some tooling to understand what's going on (and #3918 includes a very simplistic initial attempt at this directly in the tedge_mqtt_bridge crate).

My vision for this is a tedge subcommand, e.g. tedge bridge inspect <cloud>. I think it should have the following functionality:

• Prints out the active bridge rules from a template (e.g. tedge bridge inspect c8y)
• Shows any disabled rules, explaining why they're disabled
• Shows any template_rules that are effectively disabled (because the iterator in question is empty)
• Warn that the entire thing is effectively disabled if the built-in bridge isn't enabled
• Warns about unknown files in the bridge directory
• Warns about unrecognised fields
• Errors on template_rules that don't reference ${item} (and thus just generate duplicate rules)
• Warns about duplicate rules (/maybe possible duplicate rules)

The linting aspects of this should be shared with the mapper code so that passing the lints for the templates we supply is part of our tests.

The active rules should probably also be logged by tedge-mapper, so there is probably some logic to be shared there too.

Here is an example of what I came up with during some quick experimentation in #3918: