bug#5364: 23.1.91; execute-extended-command should do like FFAP

[Juri Linkov <juri@jurta.org>]

> This patch moves interactive spec into Elisp and also implements
> the following task from comments in execute-extended-command:
>
>   /* This isn't strictly correct if execute-extended-command
>      is bound to anything else.  Perhaps it should use
>      this_command_keys?  */
>
> It uses `(key-description (this-single-command-keys))' to do this.

Actually, it occured to me that displaying a key other than "M-x"
in the prompt of `execute-extended-command' is too confusing.

For instance, in bindings.el `execute-extended-command' is bound to the
[menu] key.  When I accidentally type the <menu> key, the first reaction
is "What does this mean?!" because it's very strange to see the prompt
"<menu> " waiting for a command.  It looks like a beginning of a key
sequence for the main menu.  OTOH, a well-known prompt "M-x" means
it reads an extended command.  I've added a comment that explains
why "M-x" is better than anything else.

Also we should keep the current function signature of
`execute-extended-command' unchanged and not to add a new arg
for two reasons:

1. There are places in code that call `execute-extended-command'
with one argument.

2. Calling `read-extended-command' to read a command name should not be
in the `interactive' spec because it needs to remember the hourglass
status before reading a command name (using `hourglass_started'),
and restore the hourglass (using `start_hourglass') after that.

So I installed a patch that calls `read-extended-command'
in the middle of `execute-extended-command'.

Of course, moving the whole of `execute-extended-command' to Elisp
would be better but the main obstacle is the hourglass functions
that have no Elisp interface.