SLG-0003: Error parameter implementation

[samuelmurray]

Add new methods on Logger that allows the caller to attach Errors to log events, which will be propagated to the LogHandler as-is.

Motivation:

Error information is typically of high interest in logs and log analysis. Currently, however, there is no standardized way of attaching Error information to logs, forcing users to either append it to the log message (logger.warning("Something went wrong: \(error)")), or attach it as metadata. By providing a separate parameter for this, and passing it as-is to the LogHandler, we both provide a standard, visible way to attach it, while also letting the LogHandler format it as it sees fit.
Closes #291

Modifications:

• New methods on Logger that accept an (optional) Error.
• An error property is added to LogEvent, which contains the Error from the new Logger methods.
• Adjust LogHandler implementations to serialize error as metadata.

Result:

Users of Logger can use the new methods to attach Errors to their logs, which should help unify how Errors get logged in various code bases.
LogHandler implementations can use the new error property on LogEvent and serialize it in a way that's suitable for that implementation. In general, extracting the string representation and the (qualified) type name should be a good baseline.

[samuelmurray]

Seeing as the change to LogEvent was released in 1.11.0, I opted to not provide a default implementation where the error is serialized as metadata. As I mentioned in the review for that feature, I'm not sure how we could determine if a LogHandler supports this new attribute or not. So, the best we could do is to provide a fallback for those that still do not use LogEvent - but it would feel weird to provide a fallback for old versions (<=1.10.X) but not the most recent one (1.11.0).
As far as I understood the discourse in both these proposal reviews however, most people did not see this as a huge issue. But if you see some way to provide a fallback that works for 1.11.0, I'd be happy to add it.

[kukushechkin]

Thank you for the implementation, looks great overall! Let's iron out magic metadata entries vs explict error.

[kukushechkin]

As for the failing CI checks:

• The API breakage check failing on a package method is annoying, but ok.
• Benchmarks producing slightly different values is probably due to the infra changes, let's observe on the subsequent runs.
• Tests — in the proposal we have String(reflecting:) instead of String(describing:), is there a reason to use describing:?
• And the formatting, but that one is self-explanatory.

[samuelmurray]

As for the failing CI checks:

• The API breakage check failing on a package method is annoying, but ok.
• Benchmarks producing slightly different values is probably due to the infra changes, let's observe on the subsequent runs.
• Tests — in the proposal we have String(reflecting:) instead of String(describing:), is there a reason to use describing:?
• And the formatting, but that one is self-explanatory.

Right, the reflecting vs describing was a mistake on my part, changed the tests and InMemoryLogHandler to use reflecting and added a test verifies that that we compare fully qualified names in the equality check.

[samuelmurray]

Unrelated to this PR:
Some files in this repo are getting quite long, especially Logging.swift. How about splitting it up some? For example, we could extract the included LogHandler implementations to separate files (similar to providers in swift-configuration), and maybe separate all the log methods to Logging+methods.swift.

[kukushechkin]

I've pushed an update to the benchmark thresholds, this should make it pass.

[FranzBusch]

We should probably get rid of this TestLogger and replace it with the InMemoryLogHandler at some point in the future