groot: mbr/obj-wise streaming support for types with private fields

[sbinet]

in #880, we "discovered" the reflect-based approach for reading (and writing) values for which a r/w-streamer has been generated (roops, woops, rmops, wmops) won't work when the fields of those values are not exported.

what was done in #881 was to detect when a type implements rbytes.Unmarshaler and use that (so the reflect-based code isn't used).

options to generally address this:

• use an unsafe scheme
• introduce a new interface/protocol

[bburghgr]

Thinking aloud, I would probably not go the unsafe route if I was writing this. As far as I can tell, the standard convention for (de)serialization code in Go seems handle user defined structs in one of two ways:

1. If a type implements some appropriate {Un|M}arshalX method, then use that.
2. Otherwise, (de)serialize the exported fields of the struct.

Personally, I don't think it would be much of a problem to live with the same requirements here. Especially if code generation tools can provide {Un|M}arshalROOT implementations in common use cases. Knowing very little about the groot internals, it's also the behavior I would naively expect, from having used other libraries in the past. That said, I haven't had a close look at the existing streamer code, so a little unsafe pointer math may turn out to be a less disruptive change overall.

[sbinet]

yeah, I was just brainstorming as well.

groot already has some support for automatically generating (de)serialization code from a streamer:

• https://github.com/go-hep/hep/blob/v0.29.2/groot/cmd/root-gen-type/testdata/streamers.txt
• https://github.com/go-hep/hep/blob/v0.29.2/groot/cmd/root-gen-type/main.go

a bit of work could be applied to only generate the (un)marshaling part.
keeping in mind one needs to handle UnmarshalROOT methods with multiple vX versions of a type.
(some kind of registry + dispatch, probably)

or use reflect.Value.UnsafeAddr() instead of reflect.Value.Addr().

the reflect-based solution is still appealing because there's no (manual, or through a command) code generation required.
(even if it's probably slower than the code generation approach)