sequtils: fix errors from strictFuncs use

[ee7]

Nim 1.4.x compiled the below code without error when using
--experimental:strictFuncs

import std/sequtils

type Foo = ref object

let foo1 = Foo()
let foo2 = Foo()
let foos = @[foo1, foo2]
let fooTuples = @[(foo1, 1), (foo2, 2)]

discard repeat(foo1, 3)
discard zip(foos, foos)
discard unzip(fooTuples)

However, since 2020-12-09, devel Nim produced errors like

/tmp/bar.nim(11, 15) template/generic instantiation of `repeat` from here
/foo/nim/pure/collections/sequtils.nim(172, 6) Error: 'repeat' can have side effects
an object reachable from 'x' is potentially mutated
/foo/nim/pure/collections/sequtils.nim(183, 15) the mutation is here
/foo/nim/pure/collections/sequtils.nim(183, 15) is the statement that connected the mutation to the parameter

This commit reverts some proc to func changes so that code that:

• calls repeat, zip, or unzip
• and instantiates them with types containing ref

can once again be compiled with strictFuncs. Otherwise, a user might
be forced to drop or alter their strictFuncs use when upgrading from
Nim 1.4.x, or when writing new code that uses these procedures (at least
for now, with the current strictFuncs implementation).

This commit also adds tests to assert that the remaining funcs in this
module can be compiled with strictFuncs when used with types
containing ref.

The original batch of proc to func changes in sequtils.nim was in
commit 6f57eba, which was partially reverted in 38eb021.

See also: #16305 (comment)

[Araq]

Thank you for working on this! However, before we accept your solution can we look into why the compiler still doesn't understand repeat and friends.

[ee7]

before we accept your solution can we look into why the compiler still doesn't understand repeat and friends.

Sure. This PR was just to:

• workaround to fix the things that I broke between releases
• prove that the remaining proc to func changes are OK under the current strictFuncs implementation.

I've added a reduction of the error in #16305 (comment) #20863.

Does that help? Unfortunately, anything deeper I'll probably have to leave to somebody else.