Make filtering public

[KodrAus]

This is an attempt to make env_loggers filtering more of a first-class API that people can use to build their own loggers.

I think @jethrogb's solution is actually super clever and required basically no extra code to make it work. I never would've thought to do that. But I feel like we could make filtering even more first-class at the expense of some more code to maintain. Having a Target::Silent seems a little odd, because you would never want to actually install an empty logger as the default, and is a bit of a roundabout way to get at the filtering.

There's still some cleanup and docs to do here, but I thought I'd open it up and see what people think. From the user's point of view the code looks basically the same, but I think the intent is a bit clearer when you're building your own logger, which is an important cop-out to supporting targets like files in env_logger.

r? @jethrogb

[jethrogb]

This looks mostly fine to me. The Target::Silent was kind of useless anyway, just there in case you accidentally use the logger for real.

1. Because my previous change was so minimally-invasive, I'm not super familiar with the code base.
2. I think it's pretty uncommon to have a Builder that contains another Builder inside. Normally you'd have the user construct the inner Builder manually first, build it, and then pass the built filter to the outer Builder. Are you using the current construction just for backcompat?
3. Agree docs need improvement.

[KodrAus]

I think it's pretty uncommon to have a Builder that contains another Builder inside. Normally you'd have the user construct the inner Builder manually first, build it, and then pass the built filter to the outer Builder. Are you using the current construction just for backcompat?

That's right. env_logger has a lot of dependents so I don't want to shift a lot of cheese upfront. In the future we may want to work towards DRYing out the duplicated builder methods.