add log crate adapter behind feature flag

[arferreira]

Description

• Implements log::Log trait for Logger so sheen can act as a backend for the log facade
• Any crate using log::info!(), log::warn!(), etc. gets routed through sheen's formatters
• Gated behind an optional log feature flag (sheen = { features = ["log"] })

Type of Change

• Bug fix
• New feature
• Documentation
• Refactor

Checklist

• cargo fmt ran
• cargo clippy passes
• cargo test passes
• Updated README if needed

Closes #3 (partial)

[MOZGIII]

The feature flags are dinitely a way to go here, unless you want to split into multiple crates and let the user combine fully abstracted pieces together themselves.
For a batteries included solution what I think project aims to be - this seems like good fit.

Not a big fan of the API call you have to make; better make it be included at new() somehow, or simiar; like how when a type provides a builder interface with something like A::builder().with_a().with_b().build() and A::new() is just a shorthand for A::builder().build(); in this case, however, one would have to different names, since both builder and new don't assume any side effects like initialization. But the different naming with a similar stricture could bring a simple and unified API that doesn't have this property of unsymmetic setup for adapter vs non-adapater setting.

[arferreira]

The feature flags are dinitely a way to go here, unless you want to split into multiple crates and let the user combine fully abstracted pieces together themselves. For a batteries included solution what I think project aims to be - this seems like good fit.

Not a big fan of the API call you have to make; better make it be included at new() somehow, or simiar; like how when a type provides a builder interface with something like A::builder().with_a().with_b().build() and A::new() is just a shorthand for A::builder().build(); in this case, however, one would have to different names, since both builder and new don't assume any side effects like initialization. But the different naming with a similar stricture could bring a simple and unified API that doesn't have this property of unsymmetic setup for adapter vs non-adapater setting.

Thanks for the review!
Good point on the API symmetry, I'll think about unifying the setup across adapters in a follow-up. For now shipping the functionality and iterating on the ergonomics.