Remove eager forcing of RuleInfo in substRuleInfo

substSpec updates the IdInfo for an Id, therefore it is important to not force said IdInfo whilst updating it, otherwise we end up in an infinite loop. This is what happened in #20112 (closed) where mkTick forced the IdInfo being updated by checking the arity in isSaturatedConApp. The fix is to stop the expression being forced so early by removing the call to seqRuleInfo.

This call to seqRuleInfo was introduced in 4e7d56fd where it was explained

I think there are now too many seqs, and they waste work, but I don't have time to find which ones.

We also observe that there is the ominous note on substRule about making sure substExpr is called lazily.

{- Note [Substitute lazily]

The functions that substitute over IdInfo must be pretty lazy, because
they are knot-tied by substRecBndrs.

One case in point was #10627 in which a rule for a function 'f'
referred to 'f' (at a different type) on the RHS.  But instead of just
substituting in the rhs of the rule, we were calling simpleOptExpr, which
looked at the idInfo for 'f'; result <<loop>>.

In any case we don't need to optimise the RHS of rules, or unfoldings,
because the simplifier will do that.

Before seqRuleInfo was removed, this note was pretty much ignored in the substSpec case because the expression was immediately forced after substRule was called.

Unfortunately it's a bit tricky to add a test for this as the failure only manifested (for an unknown reason) with a dwarf enabled compiler AND compiling with -g3. Fortunatley there is currently a CI configuration which builds a dwarf compiler to test this.

Also, for good measure, finish off the work started in 840df336 which renamed SpecInfo to RuleInfo but then didn't rename 'substSpec' to 'substRuleInfo'.

Fixes #20112 (closed)