Make startup subshell async to speed it up

[GivAlz]

Proposed changes

• Resolves: Start a subshell in background #4294

Checklist

init_subshell() currently forks the user's shell and then blocks synchronously until it finishes sourcing its rc file. On my mac this is very slow and it contributes to #4625 and #4781.

This PR skips that wait: init_subshell() still forks the shell at start up but does so asyncronously.
It registers the CWD-report pipe with mc's existing event-loop machinery used for
background-job progress and the steady-state prompt updates in load_prompt(), making this a minor code change.

The loading is protected: if the user tries to access the shell before the async loading is done they'll wait for it finish loading.

On My macOS I measured the change (I use oh-my-zsh and other init routines): init_subshell()'s blocking window drops from ~850ms to ~10ms.

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation --> I added some comments, I hope this is enough.

Notes

I am a long time mc user, but it has been a while since I contributed to an open source project like this: I made this change because the wait time is pushing me towards not using mc. Please let me know if there is anything I missed or I could do better. Thank you!

[zyv]

Oh man, after all the tons of work that went into fixing subshell initialization races, this sounds maximally dangerous, and it comes with no tests. I wish @egmontkob could look into this, because he did the earlier fixing, but I guess he wouldn't have time and interest. And I don't have time at the moment, unfortunately.

[GivAlz]

Oh man, after all the tons of work that went into fixing subshell initialization races, this sounds maximally dangerous, and it comes with no tests. I wish @egmontkob could look into this, because he did the earlier fixing, but I guess he wouldn't have time and interest. And I don't have time at the moment, unfortunately.

Yeah, I was kind of wondering if my "little change" would be dangerous for everything else.

I can think of some tests & try to fix the failing builds but if this step is so relevant for the whole project I understand this might wait...indefinitely...anyhow thank you!

Edit: builds are failing because I forgot to commit the test folder (sorry), I'll double check them and push them in the next days.

[GivAlz]

I force pushed because I also did a rebase.

I reviewed the tests I had written and now I pushed them. I tried to copy the style from the other tests.

[ossilator]

so much "fun" ...
i may have a look at this later, but right now i'm still a tad "indisposed".

please squash the commits, and write a proper commit message. elaborate on how the event dependencies change, which potential problems you have considered, etc. Questions raised in the long thread's on egmont's PRs may also be relevant targets. some "answers" may be best provided by test cases.