feat: modify slog.Logger to *not* satisfy slog.Sink

[cmoog]

The prior implementation allowed slog.Logger instances
to themselves be passes as slog.Sink targets. This enabled
many usage patterns that introduced extremely counter-intuitive
behavior.

This isn't just an aesthetics problem, but has caused real confusion in our monorepo. Consider the following case:

func prepareSomeService(log slog.Logger) *service {
  var srv service
  l = slog.Make(log, someOtherSink)
  srv.logger = l.Named("special-service")
  return &srv
}

Because of the nesting here, where log is a slog.Logger passed as a slog.Sink, the metadata between these two sink targets will be different. That can have unexpected behavior, like in this case logs to someOtherSink could have a different logger name than those logged to log.

As a solution, this PR modifes slog.Logger to not satisfy slog.Sink. This is a much simpler mental model... sinks are the primitive and loggers are higher-level that also hold metadata. Loggers also being sinks themselves creates more confusion than value.

To suite this particular use cases, whereby a child wants to extend a logger with an additional sinks, we should instead expose the following method

func (l Logger) AppendSinks(sinks ...Sink) Logger

[deansheather]

This looks fine. I can't think of any use case for using a logger as a sink, it doesn't really make much sense.