Implement ForallF and ForallT in terms of Forall

[treeowl]

The now-polykinded Forall is capable of expressing both
ForallF and ForallT with a few helper classes. This
confines the "trusted" portion of the module to inst.

[treeowl]

@oerjan, do you think you could check whether this modification reintroduces superclass cycles or anything else horrible?

[oerjan]

@treeowl Sorry, I had a disk crash back in October/November only a few days after I had satisfactorily set up my GitHub account, which not only wiped out some of my setup but also left all my files in backup storage. The timing felt almost like an omen. So I basically lost motivation on this. Currently I have neither GHC nor the test files on my computer. (Also, due to this and some health issues, my general following of Haskell community happenings is currently backlogged to mid-January.)

One thing I did worry about is that the new UndecidableSuperClasses system in GHC 8.0 is likely to completely change how to avoid these errors. Without further changes to the extension, I suspect that all users will need to enable it explicitly. It should eventually end up simpler but it might need code duplication to work on both < and >= 8.0.

[treeowl]

@oerjan, I'm very sorry to hear you're having troubles. I hope you get back on your feet soon.

[treeowl]

It's possible to cut down ForallT to just one helper class by using ForallF:

class ForallF p (t a) => Q p t a

This cuts out R. Unfortunately, of the two helper classes, R is more easily given a decent name (ComposeC2 or similar). If there's some advantage to doing this anyway, I can make the change.