share: share 'cachevfs' with the source clone (issue5108) Share extension now also share caches reads and writes. Not sharing caches results in costly caches recomputations which can takes up to minutes when using shares on large repositories. There are a couple of file in the '.hg/cache/' that depends of the current visibility. Visibility can be affected by the working copy location, something which is specific to each share. We ignores them for this series because they: * are the minority, * already have a good fallback to other precomputed caches, * are only affected when people use the experimental evolution feature.

cachevfs: add a devel warning for cache access though 'vfs' This will help third party extensions to migrate to the new 'cachevfs'.

cachevfs: migration the tags fnode cache to 'cachevfs' This will help sharing the cache between shares.

cachevfs: migrate tagscache to 'cachevfs' This will help sharing the cache between shares.

cachevfs: migration the revbranchcache to 'cachevfs' This will help sharing the cache between shares.

cachevfs: use the new vfs in when computing branchmap cache This will help sharing the cache between shares.

cachevfs: add a vfs dedicated to cache Most of the cache content lives in '.hg/cache/'. Moreover they are computed exclusively from data in the '.hg/store' directory. This creates issues with the share extension as the '.hg/store' directory is shared but the '.hg/cache' is not. On large repositories, this makes this prevent some usage of the share extension inefficient as some caches can take minutes to be recomputed. To improve the situation, we introduce a new 'cachevfs' that will be dedicated to cache reading and writing. In the next patches of this series, we'll migrate the 4 existing caches to it and update the share extension.

vfsward: register 'write with no lock' warnings as 'check-locks' config Update 'write with no lock' warnings in order to be better controlled by the config. We reuse the option used for lock order for these other lock related message. The message can now be disabled using 'devel.check-locks = no' (in addition to the usual 'devel.all-warnings = no').