Optimize `Sum` and `Counter` to avoid underflow/overflow logic when possible

### Motivation

As a follow-on to #89

It should be possible to avoid creating logic which considers whether an overflow/underflow has occurred by determining whether it is *ever* possible.

For example:
- If all interfaces are incrementing, and the initial value is not greater than the max (possible) value, then it cannot overflow
- If all interfaces are decrementing, and the initial value is not less than the min (possible) value, then it cannot underflow

### Desired solution

Conditionally generate the portions of the `If.block` for overflow/underflow based on analysis of the provided interfaces.

### Alternatives considered

_No response_

### Additional details

_No response_

Start by reading issue #89 and the existing Sum and Counter implementations, then trace how their provided interfaces determine the generated If.block logic. Identify the cases where overflow or underflow is impossible from the interface directions and initial bounds. Done means those checks are conditionally omitted without changing behavior in cases where overflow or underflow remains possible.

Written by the indexing model from the issue text.