fix: don't panic, only accept typed log Fields

[spikecurtis]

⚠️ This PR introduces a BREAKING change in slog's API.

fixes #221

A breaking change like this is unfortunate, but I feel strongly that it is the best path forward. The above issue gives more background, but briefly, with slog as it is without this PR, passing bad arguments to log calls will cause a panic.

With this PR, slog will not panic, and furthermore, we will have build-time checks that log call arguments are correct.

The breaking changes are that log calls of this form:

logger.Info(ctx, "dug a hole", "depth", depth, "diameter", diameter)

are no longer supported, and any code that builds an array of log fields needs to be of type []slog.Field rather than []any.

This results in a relatively small number of code changes in a big repo like coder/coder: https://github.com/coder/coder/compare/spike/slog-dont-panic?expand=1

slog's README.md has this to say in the "Why?" section:

slog has a concise semi typed API

We found zap's fully typed API cumbersome. It does offer a sugared API but it's too easy to pass an invalid fields list since there is no static type checking. Furthermore, it's harder to read as there is no syntax grouping for each key value pair.
We wanted an API that only accepted the equivalent of zap.Any for every field. This is slog.F.

At some point the decision was made to stray from this principle and we ended up in a place with no static type checking where it is easy to pass invalid fields, and we allowed a usage without syntax grouping of key/value pairs. This PR restores us to these principles.

[johnstcn]

I agree with the reasoning for this change. A couple of things:

• Per Conventional Commits, we should indicate that this is a breaking change either in the commit message or as a footer in the body.

• Since this is a breaking change, will we be releasing a new major version of slog?

• Before this change, you at least had the possibility of determining if you were logging un-marshalable values in testing. Since this is no longer the case, it would be nice if we could detect this in slogtest and fail the test.

[johnstcn]

While this is much more preferable to panicking, it does raise the possibility of unmarshal-able things at runtime. Could we possibly detect this in sloggers/slogtest and cause a test failure?