RFC: Structural logger

[asmyasnikov]

Logger interface

1. Methods Trace, Debug, Info etc. can be turned into one method Log(lvl Level), it is just a question of preferred style
2. Methods Object and Array don't have to be in Logger interface, we just need some factories to create the right objects. Putting these methods in Logger seems to be simpler than creating another interface for factories
3. Logging adapter inteface should not be sutable for arbitrary general purpose logger but should be simple enough for adapting any logger and limits library logging scope by supbset subset of options.

Record/Array interfaces

1. A lot of methods for fundamental types seems scary. But I think that this amount boilerplate will be in adapter either way. If we were to create some type Field struct {...} in SDK, the logic of type-specific marshaling would just go into Log method:

func (l *logger) Log(lvl Level, msg string, fields []Field) {
    for _, f := range fields {
        switch f.Type {
        // very big switch block with some limited number of cases and default
        }
    }
}

And this looks like an added complexity in adapter to me. I think that it's better for adapter to have a lot of boilerplate than a lot of complexity.

2. Zero-cost for disabled records is a good point. This can be done by adding some enabled flag in record and making so that all Record methods (Int, Bool, etc.) are no-op for disabled records. This however won't help optimize nested structures:

l.Trace().Array("key",
    l.Array().String("foo").Int(42), // these fields are added even if Trace is disabled
)

Need to think more about it.

3. Creating type Field struct{...} in SDK seems like duplicating some logic between SDK and adapters. For example, zap's Field looks very much like it, so zap's adapter would have to convert a bunch of ydb.Field into zap.Field. Other implementations (like zerolog) don't have such struct, and instead they encode fields directly (example). So, zerolog adapter does not need such struct at all and will look very clean and straightforward with the current interface.
4. Having Array interface which duplicates almost all methods of Record (without key string argument) also looks scary and redundant, but I still think that this boilerplate makes the resulting API less complex. I also strongly believe that supporting a lot of fundamental types + arbitrary nested structures (arrays and objects) is the best way to eliminate compatibility issues in the future. Two examples of this are already present in the PR.