Factor recursion out of gshows.

[ashokkimmel]

I wanted to use gshows, but for my specific case, certain datatypes were highly verbose but semantically void, or had a nicer implementation. I ended up rewriting gshows myself, but I feel one shouldn't need to reimplement functionality. I know this is a breaking change, but I don't think it should cause any problems. (gshowsF isn't that common a name)

[ashokkimmel]

Might also be useful for the stuff in
Data.Generics.Twins.hs
I don't feel to strongly about it so if you don't want to, feel free to close without changes.

[sergv]

@ashokkimmel Thanks for the suggestion! Seems good to me, I'm inclined to accept it.

Although introducing a new name could theoretically break someone, it's not something to avoid at all costs, otherwise we won't add anything ever.

From my perspective the worst breaking changes are changes in semantics that no-one really expects during updates since it's impossible to validate them or even know they occurred unless you're on a lookout for them. This PR doesn't do anything of the sort so no problem here.

The only one change that I request is fixing CI, cf https://github.com/dreixel/syb/actions/runs/22725545114/job/65910272037?pr=55. Enabling RankNTypes in the module should be sufficient.

[ashokkimmel]

It should be good now. I don't think this would be as good an idea for Data.Generics.Twins, as the
geq',gcompare' methods need to stay private.

[sergv]

Released as syb-0.7.4.