logging: add support for ctx and global logger

[swift1337]

Our new logger misses 2 more features that can be useful and are common in logging.
This would result in a "feature parity" with other logging libs

Ability to retrieve a global logger

Example: https://github.com/rs/zerolog?tab=readme-ov-file#simple-logging-example

package abc

import "cosmossdk.io/log"

func foo(v string) error {
  // global log.Info, Warn, Error, are exported as top-level functions  
  log.Info("Foo", "value", v)
}

Ability to get/set a logger from ctx

import (
  "cosmossdk.io/log"
  "context"
)

func bar() error {
  ctx := context.Background()
  logger := log.NewLogger(...)
  
  ctx = logger.WithContext(ctx)

  return foo(ctx)
}

func foo(ctx context.Context) error {
  logger := log.FromContext(ctx)

  logger.Info("Hello world!") 
  // ...
  return nil
}

Related:

• feat(log)!: intoduce log v2 with OpenTelemetry and slog #25701

[linear]

SDK-444

[aaronc]

So it seems that zerolog supports this, but slog doesn't. I'm not sure which other libraries do. This seems counter to the way OpenTelemetry intends for context and loggers to be used, however. Now granted, logging in OpenTelemetry is still considered to be somewhat in the early days.

But in OpenTelemetry, with tracers and spans, parent spans gets attached to the context, but the tracer does not. The tracer's purpose is to describe which package is generating spans. The context is what defines nesting.

So if we were to be consistent with this model, we would follow more the approach that otelslog takes - basically a logger is a package level thing that describes which package generates the logs. Context must be passed around to describe what other spans/metrics/logs this current log message is related to. So retrieving a logger from a context would be counter to this approach because a logger just describes the package.

If we're adopting OpenTelemetry for other instrumentation, my vote would be to stick closer to its conventions.