Major improvements in error messaging around "The command 'drush.php ... could not be executed."

Issue Summary

I have noticed that it is quite common for commands to fail with the above very unhelpful error. This does not help pinpoint the source of the issue, and rerunning with --verbose will add no further useful information in most cases. The issue could be a typo or non-existent command, or it could be that the command exists but needs a different version of Drupal core, or it could be that it depends on a module that could not be found. You cannot currently determine any of this without reading (or in some cases, debugging) drush core code.

The use case I think most people have run into at some point is running drush updatecode with the core update module disabled.

The attached patch fixes this by providing specific errors if the command is not found or if it is not executable because of unmet requirements (and listing specifically what those requirements are). To do this we alter the workflow of drush_parse_command/drush_get_commands, so that they return a matched command even if there are unmet requirements - you then check that there are no bootstrap_errors before running/listing the command. The alternative approach was to re-call drush_parse_command as second time just before we list the error, passing a $filter = FALSE parameter that is then passed into drush_get_commands, which then adds all commands (with errors added this time) rather than only adding valid commands as it would on the initial runs with $filter = TRUE. This seemed like a lot of code, and I couldn't see much value. Alternatively we could push some logic from drush_main into drush_parse_command (or some wrapper function) but again this didn't seem (to me) to really improve the clarity of the code.

Note that one useful side effect of this (which I didn't implement) was that we could, if we wanted now easily alter the help command so that when it is called explicitly (rather than just as the default command) - or perhaps when it is called with an --all parameter - it can list commands that are found but not currently executable, above the normal "smart" list of executable commands. This could be useful if you are adding your own commands and want to check that drush found them (obviously finding some commands will still be dependent on finding a Drupal site). Also, having the full unfiltered command listing allows us to potentially (in the future) add additional filtering options, such as filtering by Drupal core, dependency or bootstrap level - irrespective or the current execution environment - which could also be quite useful when the command listing starts growing.

I have tested a bunch of commands in different cases, and also the help command, but this could use a run through test before we commit. It would be really great to get this in before alpha3, since I think it could really easy the support requests.