Support bootstrapping the LoggingSystem in Lambda.run's factory

[tachyonics]

Expected behavior

It seems plausible that an application - or a higher level runtime - should use the factory method in Lambda.run as an extension point to Bootstrap the LoggingSystem along without anything else that should be created once per runtime (such as things that needs access to the EventLoop). This becomes even more likely to happen when the @main annotation is used as the actual callsite for Lambda.run may abstracted away from the end application developer.

While it is understandable that logs emitted from this factory method using the provided InitializationContext.logger[1] would not reflect any bootstrapping of the LoggingSystem, it seems reasonable that the subsequent logs emitted - particularly those from within a lambda invocation - should reflect any bootstrapping that occurred during this factory method.

[1] smoke-framework deliberately avoids creating a Logger instance until after its equivalent factory method has been called; applications are free to create a logger instance in their initialization method if they require it but they have the opportunity to bootstrap the LoggingSystem first.

Actual behavior

The Lambda runtime appears to create a single Logger instance prior to calling Lambda.run's factory method which is passed to both this factory method and mutated to create the logger instance for lambda invocations. As a Logger instance only consults the bootstrapped LoggingSystem when a new instance is created, this Logger and its mutations will always use the LoggingSystem that was active prior to the factory method.

Looking at the most recent code, it looks like the same issue would also occur with ByteBufferLambdaHandler.makeHandler.

Steps to reproduce

1. Bootstrap the LoggingSystem with something other than the default using Lambda.run's factory method.
2. Create an invocation of the Lambda.

If possible, minimal yet complete reproducer code (or URL to code)

[anything to help us reproducing the issue]

SwiftAWSLambdaRuntime version/commit hash

0.5.2

Swift & OS version (output of swift --version && uname -a)

[sebsto]

won't be fixed in v1.
v2 addresses this