Handle command retries for commands originating at the mmc layer, and

Handle command retries for commands originating at the mmc layer, and
ensure that all such commands have a non-zero retry count except for those
that are expected to fail (for example, because they are used to probe for
feature support).

While it is possible to pass a retry count down to the hardware driver in
the command request structure, no hardware driver currently implements any
retry logic.  The hardware doesn't know much about the context of a single
request, so it makes more sense to handle retries at a layer that does.

This adds retry loops to the mmc_wait_for_cmd() and mmc_wait_for_app_cmd()
functions.  These functions are the gateway from other code within mmc.c
to the hardware.  App commands are a sequence of two commands and a retry
has to rerun both of them in order, so it needs its own retry loop.

Retry looping is specifically NOT implemented in mmc_wait_for_request()
because it is the gateway for children on the bus, and they have to
implement their own retry logic depending on what makes sense for them.