mq: report correct numbers for changing "number of guarded, applied patches"

Before this patch, "hg qselect" may report incorrect numbers for
"number of guarded, applied patches has changed", because it examines
"pushable" of patches by the index not in "the series" but in "applied
patches", even though "mq.pushable()" expects the former.

To report correct numbers for changing "number of guarded, applied
patches", this patch uses the name of applied patch to examine
pushable-ness of it.

This patch also changes the result of existing "hg qselect" tests,
because they doesn't change pushable-ness of already applied patches.

This patch assumes that "hg qselect" focuses on changing pushable-ness
only of already applied patches, because:

  - the report message uses not "previous" (in the series) but
    "applied"

  - the logic to pop patches for --pop/--reapply examines
    pushable-ness only of already applied ones (in fact, there are
    some incorrect code paths)

--HG--
branch : stable
extra : rebase_source : e09f27befefecf12c9379a484e44a64547d45c96
mq: use "mq.applied[i].name" instead of "mq.appliedname(i)" for safety

Before this patch, "hg qselect --reapply" is aborted when "--verbose"
is specified, because "mq.appliedname()" returns "INDEX PATCHNAME"
instead of "PATCHNAME" in such case and "mq.push" can't accept the
former as the name of patch.

This patch uses "mq.applied[i].name" instead of "mq.appliedname(i)" as
the name of the patch to be pushed for safety.

Now, there is no code path using "mq.appliedname()", and it should be
removed to prevent developers from using it in the wrong way like this
issue.

--HG--
branch : stable
extra : rebase_source : e57d82a7b5c3118200054a41384903807c56cbef
mq: pop correct patches when changing pushable-ness of already applied ones

Before this patch, "hg qselect" with --pop/--reapply may pop incorrect
patches, because the index in "applied patches" is used to pop patches
by "mq.pop()", even though the index in "the series" should be used.

For example, when the already applied patch becomes guarded and it
follows the already guarded (= not yet applied) one, "hg qselect" is
aborted, because it tries to pop to guarded one.

This patch uses "mq.applied[i - 1].name" to pop to the patch, of which
the index in the "applied ones" is "i - 1".

--HG--
branch : stable
extra : rebase_source : cad8d3d754e5efaeda3bb660408b3841a22d529d
mq: examine "pushable" of already applied patch correctly

Before this patch, "hg qselect" with --pop/--reapply may pop patches
unexpectedly, even when all of patches applied before "qselect" are
still pushable.

Strictly speaking about the condition of this issue:

  - before "qselect"
    - there are N applied patches
    - the index of the guarded patch X in the series is less than N

  - after "qselect"
    - X is still guarded, and
    - all of applied patched are still pushable

In the case above, "hg qselect" should keep current status, but it
actually tries to pop patches because of X.

The index in "the series" should be used to examine "pushable" of a
patch by "mq.pushablek()", but the index in "applied patches" is used,
and this may cause unexpected examination of guarded patch.

To examine "pushable" of already applied patch correctly, this patch
uses "mq.applied[i].name": "pushable" is the function introduced by
the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".

--HG--
branch : stable
extra : rebase_source : 63c86c93aeb97e80e657f367569c952c55300465