refactor the crate to separate the provided configurable formater and the optional custom formatter

This crate does three things:

1. It parses environment variables into a verbosity configuration for individual modules (Env)
2. It filters log messages against said configuration (Logger.filter)
3. It provides a configurable formater (Logger.format)

You will generally read en environment, convert it to a filter and then combine the filter and a formater into a Logger which you install as default logger.

Technically all three are usable in isolation.
In practice almost everybody is using 2., most people will be using 1. with slight modifications to the default logging level, for example using verbosity flags in clis.

3 is the most commonly exchanged. This is reflected by the builder giving you the option of providing a custom formater.

This functionality should be moved to the Logger. If you want a custom formater you do not interact with the provided configurable formater in any way, but are still forced to use the type to create a Logger.

The current behaviour increases the internal complexity of the Builder struct and leads to weird api crincles. For example after calling Builder.format(|my| fn) technically every try to modify the configurable formatter (ex. format_level) should panic, as that is programmer error (unless ofc it is followed by a call to default_format).

This issue proposes to create a build_with_custom_formatter function instead. This would allow fmt::Builder to be retired.

Also since 90% of the api on the Builder is formatter options a single fn config_builder(|f: formatter|) could reduce duplication.

Start by tracing the Builder and Logger APIs described in the issue, including fmt::Builder and the custom formatter path. Compare the current formatter options with the proposed build_with_custom_formatter and config_builder designs; done means the configurable formatter is separated from custom formatting without the current API crinkles.