Fix to build with GHC 9.6

[georgefst]

For context on the tick-factor issue, see #41 and #43. The other commit essentially cherry-picks Twinside/svg-tree#29.

[ruifengx]

Is the build failing even if the factor is set to 300 (the current value in the repo)? My local build on Ubuntu WSL2 already succeeds with 300, but it takes exceptionally long time to finish. The offending module is Graphics.SvgTree.Types.Hashable, and it only contains some benign-looking pattern aliases and a bunch of orphan instances. I think the instances derived via Generic are to blame here, because I also see similar things mentioned on GHC's bug tracker. Maybe instead of raising this factor we could try to replace the offending instances by handwritten ones?

Update: compilating the Hashable module took me 2 minutes on Windows, but 10+ minutes on Fedora; both succeeds in the end, though.

[georgefst]

Is the build failing even if the factor is set to 300 (the current value in the repo)?

Huh, you're right, it isn't. Now I'm very confused about how I came to the conclusion that it was necessary.

Maybe instead of raising this factor we could try to replace the offending instances by handwritten ones?

I agree this is probably the way to go, unless we have reason to believe that the GHC issue will be fixed very soon.

[georgefst]

Is the build failing even if the factor is set to 300 (the current value in the repo)?

Huh, you're right, it isn't. Now I'm very confused about how I came to the conclusion that it was necessary.

I think I was just getting confused about versions. The factor of 300 is set here in the repo but not in the latest Hackage release.