Go: suggestion to use value receiver constructors instead of "global" factory functions
Go doesn't have built-in support for constructors, so the current codegen creates factory functions named `New*` instead (e.g. [`params_def.go`](https://github.com/kaitai-io/ci_targets/blob/6aca1b7283577518a378a52f84387d86d7f646c6/compiled/go/src/test_formats/params_def.go#L16-L21)):

```go
func NewParamsDef(len uint32, hasTrailer bool) *ParamsDef {
	return &ParamsDef{
		Len: len,
		HasTrailer: hasTrailer,
	}
}
```

I chose this approach because it seems to be widely-accepted and understood. However, it seems to me a bit cumbersome and ill-conceived. It can break autocompletion in IDEs, if you start searching for `ParamsDef` and it finds only symbols starting with that string. Due to the "condensed" naming, it's also somewhat hard to separate (distinguish) the common prefix `New` and the name of struct it's meant to construct.

Inserting an underscore between them would help (like `New_ParamsDef`), but as I understand, this is not exactly in accordance with established Go naming conventions, because `go-lint` complains about it:

```
don't use underscores in Go names; func New_ParamsDef should be NewParamsDef
```

So I wonder if there isn't some better approach for constructors in Go. I came across this article: https://scene-si.org/2018/03/08/an-argument-for-value-receiver-constructors/

There is a type `Person` that we want to construct:

```go
type Person struct {
        name string
}
```

The article claims that these two approaches are translated to the same assembly code (so they should work and perform exactly the same):

```go
func (Person) New(name string) *Person {
        return &Person{name}
}
func NewPerson(name string) *Person {
        return &Person{name}
}
```

Which is great, because one can replace `NewPerson(...)` with `Person{}.New(...)` which is much more logical and legible, and it has absolutely no performance drawback compared to the first approach.

Does it make sense? I would like to hear an opinion from any Go experts, which option they would prefer. And of course, if you know an even better solution, please share it.