Add a feature flag for logging

[BSFishy]

I think it would be better to put log statements under a feature flag. Otherwise logs could get filled with extra stuff, or difficult log filtering would need to be implemented. I think it could sometimes be nice to have logs from this crate, however I think dependents should have the option to disable them.

[veeenu]

That's a great idea, thank you. General refactoring is already planned for a new minor release sometime in the near future, so this could very well be part of that.

[veeenu]

The solution to this issue will be implemented like the rocket crate: by defining feature-flagged macros that reexport the existing macros from log if the feature is active, and do nothing otherwise.

[veeenu]

Decided to postpone this too for a later release because the implementation resulted quite tricky and I don't want to invest too much energy on it right now.

I leave a sketch of a possible solution here. It doesn't compile, tries to cloak the macros but it results in some weird scoping issues. I'd consider an alternative solution, if possible.

[veeenu]

Now that we have tracing, this might not be necessary and in fact could be dealt with by just setting up the subscribers.

@Jakobzs, you have worked on tracing, do you know how these two could be achieved and if my hypotheses are correct?

• Completely suppress logging (hypothesis: if you just don't depend on tracing-subscriber in your client, you don't pay any of the runtime cost of having tracing macros?)
• Filtering out all messages coming from hudhook (do some filtering when setting up tracing-subscriber on the client -- do you have a snippet of what this could look like?)