fix: fast memory/open file handle bail outs

[KillerCodeMonkey]

Please be kind :)

i only hacked it together, since i do not find any tests for the util methods.
it is just an idea.

1. collecting everything for each "step" for each folder
2. remove tmp files with Promise.all - hopefully there are not that much
3. binary file check in chunks - so if there only a few files it runs in parallel, else batched
4. in the last step loop over all subfolders one by one and do step 1-4

Another idea: just provide an option to pass a callback that users can override the "walkAsync" method. Providing a "files to sign" method

[KillerCodeMonkey]

@MarshallOfSound i know your comment about something like that (#286 (review)).

but without some serialization those problems will pop up again and again... even when using queuing.. since we do not know how files/folders are nested it is just a coin throw if it works or not...

My issue #325 is related to this and does not occur because of too much files open, but the size the binary check takes (i guess).

a folder with a bunch of binary files easily breaks the sign process.

And a possible slow sign process (when you really have many files) is better than a not working one when the reason is known.

PS: node 16 tests are failing in general