merge with stable

fileset: replace predicate by filesetpredicate of registrar (API) To make all built-in predicates be known to hggettext, loading built-in predicates by loadpredicate() should be placed before fixing i18nfunctions but after all of predicate decorating.

registrar: add filesetpredicate to mark a function as fileset predicate filesetpredicate is used to replace fileset.predicate in subsequent patch. This patch also adds loadpredicate() to fileset, because this combination helps to figure out how the name of "status caller" (or "existing caller") predicate is put into _statuscallers (or _existingcallers). Listing up loadpredicate() in dispatch.extraloaders causes implicit loading fileset predicate functions at loading (3rd party) extension.

registrar: remove useless base classes (API) Previous patches make these classes useless by removing classes derived from them.

revset: remove useless extpredicate class (API) Previous patch makes this classes useless by replacing it with revsetpredicate of registrar. BTW, extpredicate itself has already been broken by that patch, because revsetpredicate of registrar doesn't have compatibility with original predicate (derived from funcregistrar of registrar), in fact.

hook: filter out unstable output in tests This output is different between Python 2.6 and Python 2.7. It's also pretty irrelevant, so just filter it out.

fsmonitor: hook up state-enter, state-leave signals Keeping the codebase in sync with upstream: Watchman 4.4 introduced an advanced settling feature that allows publishing tools to notify subscribing tools of the boundaries for important filesystem operations. https://facebook.github.io/watchman/docs/cmd/subscribe.html#advanced-settling has more information about how this feature works. This diff connects a signal that we're calling `hg.update` to the mercurial update function so that mercurial can indirectly notify tools (such as IDEs or build machinery) when it is changing the working copy. This will allow those tools to pause their normal actions as the files are changing and defer them until the end of the operation. In addition to sending the enter/leave signals for the state, we are able to publish useful metadata along the same channel. In this case we are passing the following pieces of information: 1. destination revision hash 2. An estimate of the distance between the current state and the target state 3. A success indicator. 4. Whether it is a partial update The distance is estimate may be useful to tools that wish to change their strategy after the update has complete. For example, a large update may be efficient to deal with by walking some internal state in the subscriber rather than feeding every individual file notification through its normal (small) delta mechanism. We estimate the distance by comparing the repository revision number. In some cases we cannot come up with a number so we report 0. This is ok; we're offering this for informational purposes only and don't guarantee its accuracy. The success indicator is only really meaningful when we generate the state-leave notification; it indicates the overall success of the update.