Fix 'a..<b' usage after change to 'Num.Range'

[ageron]

1..<10 is now a Num.Range instead of an Iter, which broke a few things in this package.
This PR fixes this. For example, (1..<10).map(...) becomes (1..<10).iter().map(...) (until perhaps the relevant Iter functions get added to Num.Range).

[github-actions]

This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested.

If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos.

[no important files changed]

For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping @exercism/maintainers-admin in a comment. Thank you!

[ageron]

This might not be necessary anymore. I'll update this PR or close it.

Edit: for now, Num.Range only supports iter() and iter_rev().

Iter functions such as map or fold are not implemented, so this PR is indeed necessary.

[ageron]

The tests fail because the roc-test-runner uses an older version of Roc that doesn't have Num.Range yet.