Improve UX to recover files

[dacap]

Sometimes we receive mails about how to recover a session file with the session folder compressed, and they follow this guide: https://www.aseprite.org/docs/data-recovery/

I'm not sure why the data recovery fails, if it's because the UI is confusing or if there is another kind of problem, because after decompressing the folder and giving a try to the same steps, we (generally) can recover the files from the same UI (without further assistance, something they could have done in the first place).

Even more, in some extreme case we could offer the way to get the compressed session folder from the same UI.

[dacap]

Related to #2260

[Gasparoken]

Internal sample: https://igarastudio.zendesk.com/agent/tickets/5592
Sometimes a session is considered "running" here (which is incorrect):

aseprite/src/app/crash/data_recovery.cpp

Lines 151 to 153 in a406844

	SessionPtr session(new Session(&m_config, itempath));
	if (!session->isRunning()) {
	if ((session->isEmpty()) ||

and skipping sessions.push_back(session);

aseprite/src/app/crash/data_recovery.cpp

Line 163 in a406844

sessions.push_back(session);

So the session files to recover are never shown.

Additional info:
After some tests on MacOS, I found the kill(pid, 0) in:
https://github.com/aseprite/laf/blob/b8edff525c083c250ba7558c0df83d91e34e0f0e/base/process.cpp#L54-L57
returns no sense results depending on the pid number.
if the pid number saved in the pid file is 456 or 457, the recovery UI is not showed.
On the other hand, if the pid number is 453, 454, 455, the recovery UI is showed.
I've tried several values and still can't find a logical pattern, work in progress.

Update:
Every application running on OS has a 'pid' number associated with it.
Each Aseprite session is assigned with a 'pid' number, which is saved after closing Aseprite in the file named 'pid'.
When we want to recover someone else's session, or even our own session that should be listed for recovery, the following can happen:
Aseprite does not show it, because Aseprite shows only sessions to be recovered with a 'pid' number that are NOT running.
The session is detected as "not running" since the bool is_process_running(pid pid) function does not distinguish whether a 'pid' corresponds to apps not related to Aseprite (the function test ALL apps running on OS).
For example: the sample file above has the pid = 456, then if I already have any app running with pid = 456, then Aseprite won't show the recovery list.

[dacap]

@Gasparoken great discovery, probably we can fix that bug before this specific issue (which is more complex, and probably the bug is the only cause of the high amount of user support)