Updates to Logging

[danthorpe]

• Exposes the log channel via settings.
  It defaults to the shared instance, but framework consumers will be able to implement their own LogChannel and set it using:

  Log.channel = mySpecialChannel

• Removes system log (which used a private log writer)
  This will allow framework consumers to re-direct all logging through a central log channel/writer/formatter as they wish. This means, that framework consumers can use the default Log.Channel instance, but could set a special log writer, for example:

  Log.writer = mySpecialLogWriter

  which is equivalent of:

  Log.channel.writer = mySpecialLogWriter

• For platforms which support OSLog
  Added an API to use the default LogWriter (Log.Writers.OSLogWriter) but with a given instance of OSLog - this will allow framework consumers to setup the log using their own subsystem and category. Unfortunately, at this time, we can only use a single OSLog instance. It is recommended that app developers create a OSLog instance dedicated for ProcedureKit and use their bundle ID as the subsystem, and "ProcedureKit" as the category.

Created following discussions in #899

So, for example, it's now possible to do this:

Log.writer = Log.Writers.Redirecting(writers: [
    Log.Writers.OSLogWriter(log: myOSLog), 
    remoteCloudLogger])

[pronebird]

@danthorpe are devs able or supposed to use Log facilitates outside of Operations?

[danthorpe]

Well, when I initially refactored the logger, I wanted ProcedureKit contributors to be able to get logs on how the framework works, which would be separate from the logger that framework consumers might want to use for their own purposes.

But to be honest, following discussions in #899 - it's kinda easier to put everything into a single logger really.