Possible memory leak of the config map array and its C strings in `output.setConfigMap`

# Possible memory leak of the config map array and its C strings in `output.setConfigMap`

`setConfigMap` allocates the config map array plus three C strings per entry, but
`FLBPluginUnregister` only frees `p.name` and `p.description`. The array and all
`3 * len(cmap)` strings are leaked.

output/output.go:139

```go
func setConfigMap(p *FLBPluginProxyDef, cmap []ConfigMap) {
if len(cmap) == 0 {
return
}

cfg := (*C.struct_flb_config_map)(C.calloc(C.size_t(len(cmap)+1), C.sizeof_struct_flb_config_map))
entries := (*[1 << 28]C.struct_flb_config_map)(unsafe.Pointer(cfg))[:len(cmap):len(cmap)]
for i, m := range cmap {
entries[i]._type = C.int(m.Type)
entries[i].name = C.CString(m.Name)
entries[i].flags = C.int(m.Flags)
entries[i].def_value = C.CString(m.DefValue)
entries[i].desc = C.CString(m.Desc)
}

p.config_map = cfg
}
```

output/output.go:158, the function that is supposed to clean this up:

```go
// Release resources allocated by the plugin initialization
func FLBPluginUnregister(def unsafe.Pointer) {
p := (*FLBPluginProxyDef)(def)
C.free(unsafe.Pointer(p.name))
C.free(unsafe.Pointer(p.description))
}
```

Fluent Bit reads the config map during init and does not take ownership of the
allocations, which is why `p.name` and `p.description` are freed here explicitly.
`grep -rn config_map output/` shows only the three lines above, so nothing else releases
them.

This is bounded by the number of plugin registrations rather than by traffic, so it is
one leak per plugin instance rather than growth under load.

Fix: free the entries and the array in `FLBPluginUnregister`. The array is
NUL-terminated by the extra `calloc`ed entry, so it can be walked until `name` is nil:

```go
if p.config_map != nil {
e := (*[1 << 28]C.struct_flb_config_map)(unsafe.Pointer(p.config_map))
for i := 0; e[i].name != nil; i++ {
C.free(unsafe.Pointer(e[i].name))
C.free(unsafe.Pointer(e[i].def_value))
C.free(unsafe.Pointer(e[i].desc))
}
C.free(unsafe.Pointer(p.config_map))
p.config_map = nil
}
```

input/input.go:112 has the same code and the same gap; separate issue for that one.

If you could credit me as a reporter for my contributions to security advisory I will be thankful.

Start in output/output.go by reading setConfigMap and FLBPluginUnregister, then inspect the config_map references with the reported grep command. Verify that unregister cleanup covers each allocated config-map string and the array, and that the pointer is cleared without changing the separate input/input.go issue.

Written by the indexing model from the issue text.