fix: help always displayed for the first command parsed having an async handler

[mleguen]

Close #1533

After a call to .parse() for a command with an async handler, next calls to parse, if they need to display help, display help for this command.

[bcoe]

@mleguen caching in general can lead to some gnarly bugs (I've heard it called "one of the hard problems in computer science").

Another option, do we stop caching, how much do we care about the performance gain? Or did we add caching to address another bug?

[mleguen]

This is not a performance cache, only something to still be able to display help for the command whose async handler is "running in the background" when yargs returned and can already have been modified.

IMHO, this is a bad idea anyway, so I would be happy to drop it.

[bcoe]

@mleguen would we regress a bug that the cache was added to address? I would prefer simplifying if we think this is a feature that people don't need too often ... it might be worth keeping if we specifically added this to address problems.

[mleguen]

@bcoe Here is what I suggest:

• we merge this PR first to fix Bug: .parse not resetting context #1533
• we do not drop caching as it is still useful for applications not calling parse on the same yargs instance several times (and we have no better solution at the moment with yargs not being async)
• we deal with Help is displayed twice when an async handler fails with exitProcess(false) #1534 by stating in the docs that command handlers should not return a promise if parse is to be called several times