logging: change logging format to drop "[file:line] func():" part

logging: change logging format to drop "[file:line] func():" part

Choose a new logging format.

- the logging format must not be configurable and it must be the
  same for all backends. It is neat that journal supports additional
  fields, but an average user still posts the output of plain
  journalctl, without "--output verbose" (which would also be hard
  to read).
  Also, we get used to a certain logging format, so having different
  formats is confusing. If one format is better then another, it should
  be used for all backends: syslog, journal and debug.
  The only question is, what is the best format.

- the timestamp: I find it useful to see how much time between two
  events passed. The timestamp printed by syslog doesn't have sufficient
  granularity, and the internal journal fields are not readily available.
  We used to print the timestamps for <error>, <debug> and <trace>,
  but ommited them for <info> and <warn> levels. We now print them for
  all levels, which has a uniform alignment.

- the location: the "[file:line] func():" part is mostly redundant
  and results in wide lines. It also causes a misalignment of the
  logging lines, or -- as I recently added alignment of the location --
  it results in awkward whitespace and truncation.
  But the location is really just necessary because our logging messages
  are bad:
    "<debug> [1456397604.038226] (9) 11-dhclient succeeded"
  The solution to this is not
    "<debug> [1456397604.038226] [nm-dispatcher.c:358] dispatcher_results_process(): (9) 11-dhclient succeeded"
  but a properly worded message:
    "<debug> [1456397604.038226] dispatcher: request #9, script 11-dhclient succeeded"

- logging-message: we need to write better logging messages.
  I like some form of "tags" that are easy to grep:
    "platform: signal: link changed: 4: ..."
  Downside is, that this is not nice to read as a full sentence.
  So, especially for <info> and <warn> logging, more human readable
  messages are better.
  We should find a compromise, where the log message explains what
  happens, but is still concise and contains patterns that are easy
  to grep and identify visually.

https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00077.html