hidden: invalidate hiddenrevs when needed The `hiddenrevs` cache is volatile too (It use content from `obscache`). When unsure it is invalidated when necessary. In a near future, the cache will probably be moved to `revsfiltercache`

cache: group obscache and revsfiltercache invalidation in a single function Both caches are very volatile and needs invalidation on the same kind of event. revsfiltercache actually depends on the content of revsfiltercache.

clfilter: use filtering in `visibleheads` This is the second real use of changelog filtering. The change is very small to allow testing the new filter with a setup close to the original one. We replace custom post processing on `heads`function by call to the standard code pass on a filtering repo. In later coming will have wider usage of filtering that will make the dedicated function useless.

clfilter: use filtering in `visiblebranchmap` Here is the first real use of changelog filtering. The change is very small to allow testing the new filter with a setup close to the original one. We replace custom post processing on branchmap function by call to the standard code pass on a filtering repo. In later coming will have wider usage of filtering that will make the dedicated function useless.

clfilter: introduce a "unserver" filtering mode This mode is for repository used as a server. It filter secret and hidden changeset out. It is put to use in later changeset.

clfilter: add a cache on repo for set of revision to filter for a given set. Recomputing the filtered revisions at every access to changelog is far too expensive. This changeset introduce a cache for this information. This cache is hold by the repository (unfiltered repository) and invalidated when necessary. This cache is not a protected attribute (leading _) because some logic that invalidate it is not held by the local repo itself.