Add support for adding custom log layers

[johanhelsing]

Objective

• Currently, custom log layers can not co-exist with LogPlugin
• This makes it hard to integrate with other error diagnostics solutions like automatic error reporting, saving logs to files, etc. without also losing the normal functionality of bevy's logging
• Enabler for Bevy Log Output to Files #5233, alternative to Log to file #5342

Solution

• Add a number of user-specified, boxed Subscribers to LogPlugin's settings

---

Additional notes

Draft PR because how extra_layers is passed in (Arc<Mutex<Option<Vec>>>) is pretty ugly. I'm not sure what the current idiom of letting Plugin::build take ownership of something is? Should it be in a resource instead?

[geieredgar]

After this comment #8101 (comment) for my PR

note this potentially goes would go against cart's comment here that plugin build should be stateless.

#4212 (comment)

Something else worth calling out: consuming self would mean that the Plugin's init isn't a repeatable process, which might come in handy for things like editors, hot reloading, etc.
I think we should be moving in the direction of "plugins are completely stateless by default and configured with an instance of a specific type (ideally with a default impl)"

I think that the best approach would be to use Box<dyn Fn() -> Vec<_>> as type for extra_layers with Box::new(|| Vec::new()) as default value. And then branching on empty/non-empty Vec. Would that work for you?

[alice-i-cecile]

Closing; similar work was completed in #10822.