[SCFToCalyx] Fix improper usages of RewritePatterns

Nobody has claimed this yet.

This is the issue we encountered in https://github.com/llvm/circt/pull/4353, but since we only landed a workaround to the root cause issue, I'm breaking this out into a separate issue.

cc @mortbopet @mikeurbach

I think #4353 probably has most of the details, but just to summarize, the SCFToCalyx convertor is misusing RewritePatterns in a few places, where it is not modifying the target op and instead inserting a new op, relying on a later RewritePattern to eventually delete the targeted op. This is problematic because the PatternRewriter infrastructure is designed to match on a certain pattern and then rewrite it into some other form, and there are assumptions it makes about idempotency and keeping track of mutations.

I don't know the SCFToCalyx code very well, but I think one way to fix this would be to take all of the `addOncePattern()` patterns defined in that code and rewriting them to not use the PatternRewriter system at all, instead keeping track of state on a custom class local to the SCFToCalyx converter.

We probably want to work on this sooner rather than later, since we don't know how long our workaround will continue working as upstream MLIR continues to change.

Start by reading the SCFToCalyx converter and the details in PR #4353, then locate each addOncePattern() usage. Trace how these patterns interact with PatternRewriter and later deletion patterns; done means the converter no longer relies on those improper usages and the existing workaround remains unnecessary.

Written by the indexing model from the issue text.