Deprecate PEcAn.logger in favor of log4r?

[Aariq]

Might be more trouble than its worth at this point, but on the other hand, on a cursory look, it seems like log4r does everything PEcAn.logger does and that would mean one fewer packages to get on CRAN and maintain.

https://github.com/johnmyleswhite/log4r

[Sweetdevil144]

In fact log4r offers much more used logs other than our PEcAn.logger offers currently. This might become one of our first step for tackling the Optimization of PEcAn project under GSoC.
Any takes on this @infotroph ?

[mdietze]

I don't have a stong objection, but I also file this under the category of "if it's not broke, don't fix it". There's a number of places in PEcAn where the code is genuinely buggy and unreliable, and I'd personally prioritize those fixes over ones that are mostly aesthetic, especially since this swap could actually introduce new bugs as we learn how to use log4r. Also creates an additional external dependency, which could leave us in a pain point when this package breaks, is deprecated, is upgraded to new syntax, or is dropped by CRAN. All these things have happened to us many time with other packages.

[infotroph]

I agree with Mike. I have some ideas about ways we could improve logging around the edges*, but what we have basically works and any changes to it are low priority.

*In particular: I think it may be possible to have the logger register itself as a condition handler so that it can handle built-in message/warning/stop calls without the package that generates those messages needing to import anything. Slapping together a demo version of that has been low on my list for several years now...