make asynccache/addcol-shell thread-safe, and runnable in macros and replay

[midichef]

This PR fixes failure of addcol-shell in replay mode or macros, where the resulting column has no shell output, just an error in every cell. It also fixes a race condition where most cells would have the expected output, but a rare cell could be empty with an error. Closes #2786.

[midichef]

Demonstration of the errors
The failure in replay/macros is this: when addcol-shell is run in a replay file or a macro, it gives an error running calcValue() for each cell:

        File "/home/midichef/.venv/lib/python3.12/site-packages/visidata/shell.py", line 60, in <lambda>
            Column(cmd+'_stdout', type=bytes.rstrip, srccol=shellcol, getter=lambda col,row: col.srccol.getValue(row)[0]),
        TypeError: '_MainThread' object is not subscriptable

This error can be demonstrated with vd -b -i -p shellcol.vdj using a replay file shellcol.vdj:

#!vd -p
{"sheet": "", "col": "", "row": "", "longname": "open-file", "input": "sample_data/benchmark.csv", "keystrokes": "o", "comment": "", "replayable": true}
{"sheet": "benchmark", "col": "Date", "row": "", "longname": "addcol-shell", "input": "echo $SKU", "keystrokes": "z;", "comment": "", "replayable": true}

To demonstrate the race condition possibility, put this in .visidatarc:

import random, time
@VisiData.after
def execAsync(vd, func, *args, **kwargs):
    # run only for the @asynccache commands
    if len(args) == 3 and 'ColumnShell: echo $SKU' in repr(args[0]):
        if random.randint(1,4) < 3:
            time.sleep(0.5)

then run vd sample_data/benchmark.csv and do z; and input echo $SKU. After several seconds of delay, the new columns appears. Several cells, but not all, should be blank with errors.

[midichef]

The use of setdefault is apparently a common way to read/write a dict value safely as an atomic operation. A long comp.lang.python thread from 2018 gives a sense that it is fairly standard. This python.org thread from 2024 implies that the lack of explicit guarantees is deliberate. I've gathered that using this technique is common enough to be safe, and future implementations of CPython won't casually break this use case.

However, I don't know anything about how the removal of the GIL will affect this implementation. But for today's CPython, this PR is safer than the existing code.

[saulpw]

Thanks for figuring this out, @midichef! The fix looks good to me.

[midichef]

Okay, I've moved the comments into the commit message.