fix: support natural ordering for numbers with >12 digits

[XeroOl]

Changes the column ordering code when view_options.natural_order is enabled, so that it can support larger numbers.

I chose to handle numbers of up to 999 digits, because some cursory research seems to suggest to me that most filesystems cap at 255 bytes per segment, and 999 > 255, so it should be sufficient for all actual filenames.

Performance may have changed but I don't know if it will be better or worse.

I've slightly increased the complexity of the string.format format specifier, but the final strings will be shorter on average, and string.format no longer has to implicitly coerce int from a string into a number.

before:

after:

[XeroOl]

With the original natural order PR you said you did benchmarking. I'm curious what the methodology was, because I want to know if I've improved performance at all

[XeroOl]

Okay I've run the benchmark (with make benchmark)

On my computer:
No natural ordering: 686ms
Natural ordering (current): 1.6s
Natural ordering (with my changes): 2.0s

So this PR does slow down the code.

If this is a problem I would be happy to work on performance.

[XeroOl]

Okay! I've fixed the performance! The main problem is that the sort key callback is being called many times repeatedly for each item. I added memoization so that the key only needs to be computed once per sort.

(Also I swapped an unpack with manual indexing, to avoid a luajit trace stitch)

Before this PR:

command	time
make benchmark	660ms +- 45ms
make benchmark (with natural sort)	1.6s +- 45ms

After PR:

command	time
make benchmark	607ms +- 8.0ms
make benchmark (with natural sort)	783ms +- 32ms

[stevearc]

Nice work! I appreciate the iteration on performance