This adds support for using HeliumLogger as a SwiftLog backend.

Description

Bootstrap SwiftLog

This makes it possible to bootstrap the SwiftLog logging system in a few different ways.

Convenience API
There is a convenience API to bootstrap SwiftLog using HeliumLogger.

HeliumLogger.bootstrapSwiftLog()

You may optionally customize the default HeliumLogger instance used with SwiftLog using a configuration closure.

HeliumLogger.bootstrapSwiftLog { heliumLogger in
    heliumLogger.colored = true
}

LoggingSystem API

You can bootstrap the SwiftLog logging system directly using a static factory method on HeliumLogger.

LoggingSystem.bootstrap(HeliumLogger.makeLogHandler)

Alternatively, you can bootstrap using an existing HeliumLogger instance. This allows for customization of the HeliumLogger instance.

let heliumLogger = HeliumLogger()
heliumLogger.colored = true

LoggingSystem.bootstrap(heliumLogger.makeLogHandler)

Using SwiftLog

Once the logging system is bootstrapped, you can use SwiftLog's Logger as usual and HeliumLogger will be used to generate the output.

var logger = Logger(label: "MyLogger")
logger.logLevel = .trace
logger.trace("This is a trace")

Example output:

[2019-07-09T20:06:41.779-07:00] [MyLogger] [trace] [TestSwiftLog.swift:50 testTrace()] This is a trace

Motivation and Context

SwiftLog is primarily an API package and needs SwiftLog-compatible logging backends.

From SwiftLog:

As the API has just launched, not many implementations exist yet.
…
This API package does actually include an overly simplistic and non-configurable logging backend implementation which simply writes all log messages to stdout.

This adds a more mature logging backend to the SwiftLog ecosystem.

How Has This Been Tested?

I added an XCTestCase to test the SwiftLog implementation (TestSwiftLog.swift). These tests are primarily focused on exercising the new API and follows patterns from TestLogger.swift.

All tests are passing on macOS and Linux using Swift 4 and Swift 5 toolchains.

Impact on Existing Code

There are no source-breaking changes to the public API.

However, this does expand the surface area of the HeliumLogger API and introduces potential confusion by supporting two different logging APIs with inherent differences. For example:

• HeliumLogger instances may be initialized using a LoggerMessageType that is ignored when used with SwiftLog.

• HeliumLogger is a class with reference semantics. SwiftLog expects a Logger to have value semantics.

• Log segments were added to HeliumLogger that are specific to SwiftLog (label / metadata).

Longer term, it may make sense to create a generic logger package and provide separate packages for SwiftLog and LoggerAPI support, but this pull request aims to provide a much lower touch solution.

Overall, I'm hoping that the benefits of supporting the SwiftLog API are worth these tradeoffs.

Feedback welcome!

cc @ianpartridge @djones6