python2.4: fix imports of sub-packages of the email package

These all have an obvious comment so if/when we finally ditch Python
2.4 we can eradicate them easily.
merge: let the user choose to merge, keep local or keep remote subrepo revisions

When a subrepo has changed on the local and remote revisions, prompt the user
whether it wants to merge those subrepo revisions, keep the local revision or
keep the remote revision.

Up until now mercurial would always perform a merge on a subrepo that had
changed on the local and the remote revisions. This is often inconvenient. For
example:

- You may want to perform the actual subrepo merge after you have merged the
parent subrepo files.
- Some subrepos may be considered "read only", in the sense that you are not
supposed to add new revisions to them. In those cases "merging a subrepo" means
choosing which _existing_ revision you want to use on the merged revision. This
is often the case for subrepos that contain binary dependencies (such as DLLs,
etc).

This new prompt makes mercurial better cope with those common scenarios.

Notes:

- The default behavior (which is the one that is used when ui is not
interactive) remains unchanged (i.e. merge is the default action).
- This prompt will be shown even if the ui --tool flag is set.
- I don't know of a way to test the "keep local" and "keep remote" options (i.e.
to force the test to choose those options).


# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@gmail.com>
# Date 1378420708 -7200
#      Fri Sep 06 00:38:28 2013 +0200
# Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d
# Parent  50d721553198cea51c30f53b76d41dc919280097
merge: let the user choose to merge, keep local or keep remote subrepo revisions

When a subrepo has changed on the local and remote revisions, prompt the user
whether it wants to merge those subrepo revisions, keep the local revision or
keep the remote revision.

Up until now mercurial would always perform a merge on a subrepo that had
changed on the local and the remote revisions. This is often inconvenient. For
example:

- You may want to perform the actual subrepo merge after you have merged the
parent subrepo files.
- Some subrepos may be considered "read only", in the sense that you are not
supposed to add new revisions to them. In those cases "merging a subrepo" means
choosing which _existing_ revision you want to use on the merged revision. This
is often the case for subrepos that contain binary dependencies (such as DLLs,
etc).

This new prompt makes mercurial better cope with those common scenarios.

Notes:

- The default behavior (which is the one that is used when ui is not
interactive) remains unchanged (i.e. merge is the default action).
- This prompt will be shown even if the ui --tool flag is set.
- I don't know of a way to test the "keep local" and "keep remote" options (i.e.
to force the test to choose those options).
mq: simplifies the refresh hint in checklocalchanges

The `checklocalchanges` function in the `mq.queue` class takes a `refresh` argument that
changes the error message of raised exception. When refresh is
`True` the exception message is "local changes found, refresh first" otherwise,
the message is just "local changes found".

This changeset is the first of a series that extract `strip` into a standalone
extension (as discussed in issue3824). This `checklocalchanges` function is
indirectly used by the strip command. But in a standalone strip extension the
concept of "refresh first" has no sense. In practice, When used in the context
of the strip commands `refresh`'s value is always `False`.

So my final goal is a be able to extract the `checklocalchanges` logic in a
standalone extension but to keep the part related to "refresh first" in the mq
extension. However the refresh handling is deeply entangled into the
`checklocalchanges` code. It is handled as low a possible at the point we raise
the exception.

So we moves handling of refresh upper in the `checklocalchanges` code. This will
allow the extraction of a simple version in the strip extension while mq can
still inject its logic when needed.

Two helper functions `localchangesfound` and `localchangedsubreposfound` died in
the process they are replaced by simple raise lines.
mq: extract checksubstate from the queue class

This function does not need any of the the `mq.queue` method or attributes. It
is indirectly used by the `strip` command. We are trying to extract this command
in a standalone extension as discussed in issue issue3824.
mq: extract checklocalchanges from `mq.queue`

The core part of `checklocalchanges` is now mq independent. We can extract it in
a standalone function to help the extraction of `strip` as discussed in issue3824.

A `checklocalchanges` function stay in `mq.queue` with the part related to
"refresh first" messages.
mq: use the new checklocalchange in the strip command

The strip command never use the `refresh` argument. So we can use the function
we just extracted.
mq: document repo.mq.qparents

The function is not very complex but writing this doc helped me to check if
I got everything right.
mq: drop the use of mq.queue.qparent in mq.strip

In this case, rev is never `None`. We can just copy the two relevant lines in
in `strip`. This help having `strip` independent from `queue` one
further step toward its extraction in an independent extension. (As
discussed in issue3824).
mq: drop the use of mq.queue.qparent in mq.queue.strip

Same as in the previous changeset, rev is never `None`. We can just copy the two
relevant lines in in `queue.strip`. This help having `queue.strip` independent
from `queue`. One further step toward the extraction of `strip` in an independent
extension. (As discussed in issue3824).
mq: extract `mq.queue.strip`

It does not depend on `mq.queue` anymore.
mq: have the strip command functionnal on repo without mq

This is the last step before being able to extract `strip` in its own extension.
The changes are made in mq to allow a move only extraction without touching a
line of code.
histedit: remove unused parents() call