.golangci.yml: enable recvcheck

[tarasmadan]

The plan was to make a few trivial fixes, but something went wrong...

[dvyukov]

What is it checking? What are the warning? Is it fixing bugs, or style?

Lots of semantic changes, some are affecting performance, but unclear why the new code is better.

[tarasmadan]

Is it fixing bugs, or style?

Short answer - mostly style.
The recommendation is to make all receivers *T or T and to not mix them.
Dave Chaney also mentioned the data races which are happening when you write to some field in goroutine using *T and call some T method which reads the field.

https://go.dev/doc/faq#methods_on_values_or_pointers

_Next is consistency. If some of the methods of the type must have pointer receivers, the rest should too, so the method set is consistent regardless of how the type is used. See the section on method sets for details.

For types such as basic types, slices, and small structs, a value receiver is very cheap so unless the semantics of the method requires a pointer, a value receiver is efficient and clear._

https://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t

[tarasmadan]

#5761 to only delete unused

[dvyukov]

Look fine to me, I will defer to Aleksandr since it touches prog expressions code.