destroyed: invalidate phraserevs cache in all case (issue3858)

When revisions are destroyed, the `phaserevs` cache becomes invalid in most case.
This cache hold a `{rev => phase}` mapping and revision number most likely
changed.

Since 1c8e0d6ac3b0, we filter unknown phases' roots after changesets
destruction.  When some roots are filtered the `phaserevs` cache is invalidated.
But not if none root where destroyed.

We now invalidate the cache in all case filtered root or not.

This bug was a bit tricky to reproduce as in most case we either:
* rebase a set a draft changeset including root (phaserev invalidated)
* strip tip-most changesets (no re-numbering of revision)

Note that the invalidation of `phaserevs` are not strictly needed when only
tip-most part of the history have been destroyed. But I do not expect the
overhead to be significant.
obsolete: extract foreground computation from bookmark.validdest

This foreground logic will be reused by update logic.
update: allow dirty update to foreground (successors)

Update to "foreground" are no longer seen as cross branch update. "Foreground"
are descendants or successors (or successors of descendants (or descendant of
successors (etc))). This allows to update with uncommited changes that get
automatically merged.

This changeset is a small step forward. We want to allow dirty update to
"background" (precursors) and takes obsolescence in account when finding the
default update destination. But those requires deeper changes and will comes in
later changesets.