feat: ReplaceTypes: recursively replace on types too

[acl-cqc]

Follow-up to #2435 - as the test demonstrated, if we recursively replace within ops, we need to do types as well (if the op replacements change their input/output types), due to e.g. Input/Output.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.59%. Comparing base (5f53767) to head (9e53017).

Additional details and impacted files

@@                   Coverage Diff                   @@
##           acl/replace_recursive    #2442    +/-   ##
=======================================================
  Coverage                  82.59%   82.59%            
=======================================================
  Files                        247      246     -1     
  Lines                      45988    45879   -109     
  Branches                   41622    41615     -7     
=======================================================
- Hits                       37982    37893    -89     
+ Misses                      5987     5967    -20     
  Partials                    2019     2019            

Flag	Coverage Δ
python	91.51% <ø> (+0.25%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[acl-cqc]

At this point I am groaning and wishing that maybe I hadn't gone this way.....but, it does continue the theme of, make the framework do the work - I am thinking to put in a breaking change next that changes ReplacementOptions::default() to turn on recursion, hence, normal users won't have to turn this on and it'll just happen.

Actually, I can do that by deprecating the non-options variant, and adding a new variant with a different ReplacementOptions....even in the same PR....