[mathiasrw]

Closes #814

Stacked on #829.

Change

The numbers of #791 cost time also in runs that do not use them:

• The code put in front of the --js code now only makes the numbers the code uses. Before, about 120 variables were made for each match when the code ran once per match.
• The files are no longer searched one more time to count them for $i and $c. A file counts for $i when the code runs for a match in it, and for $c when its content changed, both known as the file is worked on. Before, every file was searched again in every run, also without --js.

rexreplace '(foo)' '$1.toUpperCase()' m.txt --js -o with 20,000 matches, Bun on a Mac:

	Time
Before	2.09 s
Now	0.09 s
Now, with code that uses $M	0.75 s

Tests

yarn test-ci passes, and the tests of #791 still pass. There is no new test of the speed, as it would be flaky in CI.

From the review of 23 October.

After the review of 24 October

• The help of --js says that a number is only made when the code names it, so a name built when the code runs, like eval('$' + 'n'), is not there.
• The text above no longer says that this can not be seen from the code.

Follow-up

The --js help says it shorter, and the sentence on once per match is folded into it: "For speed, only the numbers the code names are made, and the code runs once per file unless it names the match, a group, $m or $M. This is found with a simple text search, so it can be fooled, like by eval('$' + 'n')." The README line is in #838.

Follow-up

All the numbers are made every time, as values of the function that runs the code, and not as var code put in front of it. So they cost nothing to compile:

20 000 matches, (foo) $1.toUpperCase()	Time
Before #791 (from the issue)	0.22 s
main	1.91 s
This PR	0.22 s

$i is counted when the code runs for a match in the file, so there is no extra search of each file.

The help says only: "For speed, the code runs once per file unless it names the match, a group, $m or $M."

test/fix/814.test.js is new: a file with no match is skipped by $i and $c.