Resolve "BEC_Service/Logger improvements"

Description

A complete refactoring of how logging is handled in BEC would be beneficial (having it independent of BECService, having proper logging handlers hierarchy like bec.bec_lib.*, bec.bec_ipython_client, bec.bec_servers.device_server.* etc), and probably using standard logging, which provides more flexibility than loguru for advanced stuff. Just an example: why having to remove all handlers just to change level ? However, the logging module in Python is highly configurable with many possibilities, and its API is inspired by Java, rather old school... so yes, it hurts...

Meanwhile, this MR proposes:

• use of sys.__stderr__ instead of sys.stderr for screen output
  • for example for BEC GUI server it allows to redirect sys.stderr to log file without being in a "recursion"
• console log is now opt-in, it has to be explicitely requested
  • since it is only used by BEC IPython client

This MR does not add the possibility to specify a name for the logger, because it is too intricate as it is now; name would have to be added to BECClient, then propagated to BECService... As already said the fact BECClient is a BECService could be refactored as well. Why client, which main role is to connect to Redis, should have a "service name" ? Which is in turn used to give the log file name... This is confusing. In addition instantiation of those objects occurs after the processes are already started - usually it is better to define logging very close to the start of the process, so it is available and ready asap.

Closes #316 (closed)