subscriber: added builder for filter Directive

[rustonaut]

Motivation

1. There are some filters which can not be created with the current Directive string repr syntax, like e.g. the strings bool, 1 or 2.3 or values containing characters including but not limited to }], (for some of this there are partial fixes in other PRS). Furthermore updating the syntax the accommodate this is always a potential braking change, one which also can be subtle to detect.

2. Sometimes there is need to create Directives programmatically, e.g. from a different kind of logging config or to set more complicated defaults.

3. We might want to add other matching capabilities in the future which might not be re presentable in the string syntax (or at least entail a braking change). Like e.g. matching fields regex, matching based on dyn Value, a field matching the string true and boolean true at the same time, etc.

By allowing programmatic creation of Directives we allow downstream users to work around existing issues, experiment with solution to such issues in external crates and in addition set the foundation for adding future matching capabilities in the future.

Solution

• adds Directive::builder() / DirectiveBuilder
• ValueMatch is now public as we need it in the builder. But we wrapped the current implementation instead of exposing it so that we can freely change/extend it in the future.

Cavets

• as we now can create filters which can not be represented with the parser (without making a breaking change to the parsing format) we no longer have the guarantee that a Display <=> FromStr round trip works

Out of Scope

• currently the only way to add build Directives is by using EnvFilter::add_directive, which means there always is "some" parsed or default directive in the EnvFilter before we can add our directives. We could e.g. impl FromIterator<Directive> for EnvFilter or allow adding directives instead of parsing for building the builder. But that is outside of the scope of this PR.

Workaround For: #1584, #1181
Fixes: #2507, #404
Refs: #1584, #1181

[rustonaut]

❓ Should env/directive.rs be moved to env/directive/mod.rs?

[rustonaut]

❗ Currently we could add all of this methods directly onto Directive but as idk. if that will be the case in the future I added a builder.

[rustonaut]

For building directives this needs to be a public type in some form, the reason why I choose a wrapper instead of #[non_exhaustive] is:

• like #[non_exhaustive] we can add variants
• but we also can fully change the internal representation
• and we don't want to expose MatchDebug and MatchPattern
  • through we could give them a public interface, too
• we wan to prevent people from creating a F64(f64::NAN)

I still could change it to a pub #[non_exhaustive] enum if desired.

[rustonaut]

Preferably I would have added this block just above the ==== impl ValueMatchInternal ==== block but that would have introduced many more line changes as some existing impl where outside of their section.

[rustonaut]

Pulled up so that after this PR all impl ValueMatch are under the same ==== impl ValueMatch === section.